Hi Jeff, > At LSF this year, there was a discussion about the "wishlist" for > userland file servers. One of the things brought up was the goofy and > problematic behavior of POSIX locks when a file is closed. Boaz started > a thread on it here: > > http://permalink.gmane.org/gmane.linux.file-systems/73364 > > Userland fileservers often need to maintain more than one open file > descriptor on a file. The POSIX spec says: > > "All locks associated with a file for a given process shall be removed > when a file descriptor for that file is closed by that process or the > process holding that file descriptor terminates." > > This is problematic since you can't close any file descriptor without > dropping all your POSIX locks. Most userland file servers therefore > end up opening the file with more access than is really necessary, and > keeping fd's open for longer than is necessary to work around this. > > This patchset is a first stab at an approach to address this problem by > adding two new l_type values -- F_RDLCKP and F_WRLCKP (the 'P' is short > for "private" -- I'm open to changing that if you have a better > mnemonic). > > For all intents and purposes these lock types act just like their > "non-P" counterpart. The difference is that they are only implicitly > released when the fd against which they were acquired is closed. As a > side effect, these locks cannot be merged with "non-P" locks since they > have different semantics on close. > > I've given this patchset some very basic smoke testing and it seems to > do the right thing, but it is still pretty rough. If this looks > reasonable I'll plan to do some documentation updates and will take a > stab at trying to get these new lock types added to the POSIX spec (as > HCH recommended). > > At this point, my main questions are: > > 1) does this look useful, particularly for fileserver implementors? > > 2) does this look OK API-wise? We could consider different "cmd" values > or even different syscalls, but I figured this makes it clearer that > "P" and "non-P" locks will still conflict with one another. > > Jeff Layton (5): > locks: consolidate checks for compatible filp->f_mode values in setlk > handlers > locks: add definitions for F_RDLCKP and F_WRLCKP > locks: skip FL_FILP_PRIVATE locks on close unless we're closing the > correct filp > locks: handle merging of locks when FL_FILP_PRIVATE is set > locks: show private lock types in /proc/locks I haven't looked at the patches, but it would be very good to have locks per "open" and not per "fd". What happens in this example? fd1 = open("/somefile", ...); fd2 = open("/somefile", ...); fd3 = dup(fd1); lock(fd1, range1) lock(fd2, range2) lock(fd3, range3) lock(fd2, range1) // => error already locked? lock(fd3, range1) // stacked lock? close(fd1) lock(fd2, range1) // is range1 still locked by fd3 ? What about fd-passing, will the locks be transferred/shared with the other process? metze -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
