[NFS-Ganesha-Devel] Implementing RFC 5661 Section 9.5. Issues with Multiple Open-Owners

Currently the way Ganesha handles lock owners for NFS v4.x works for many cases, but there are issues. Ganesha links each lock owner with an open owner. It also links each lock stateid with an open stateid. There can be multiple lock owners per open owner and in parallel multiple lock stateids per open stateid. But we do not support a single lock owner tying to multiple open owners as RFC 5661 Section 9.5. Issues with Multiple Open-Owners details. One thing we could do is stop associating a lock owner with an open owner. Looking through the code, this linkage seems to be only used in logging. However, we need a per lock owner per file entity to hang lock state off of. This looks like a stateid, however, Section 9.5 suggests there could be multiple stateids for each lock owner/file pair, and locks SHOULD be associated with the most recent stateid they were acquired with. A problem for Ganesha with this is that FSAL_VFS has an open file description (and file descriptor) per lock stateid. This is what it ties locks (using the kernel OFD Locks) to represent the different lock owners. But we then can't move a lock from one stateid to another (or at least we can't move an exclusive lock). So while we COULD have one stateid per lock owner/open owner/file tuple, it doesn't help us. One possibility is we create an additional object that represents a lock owner/file association. That entity holds all the FSAL locks for a given lock owner/file association, while individual locks are also tied to a specific stateid in the SAL layer. The SAL could easily handle moving locks from one stateid to another when the stateids represent the same lock owner. This solution would add an additional ref-counted object. This new object would be another form of state_t to keep the FSAL logic the same, but would no longer have an associated open state (which is fine, vfs_lock_op2 should never need the open state). Each lock state would however refer to the lock owner state, and thus if a lock state was passed to a read2 or write2 FSAL method, the FSAL could use any of 3 file descriptors (the open state, the lock state, or the new lock owner). The lock state though might not have an fd associated with it. I'm trying to think of another way to implement this, and so far this sounds like the only path that will work. Frank