Re: [RFC PATCH 0/5] locks: implement "filp-private" (aka UNPOSIX)locks

From: Stefan (metze) Metzmacher
Date: Sat Oct 12 2013 - 05:20:52 EST


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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/