Questions about private file locks (Re: Proposed new krb5 FILE ccache protocol)

[Jeff Layton]

Simo forwarded these questions to me:

> On Tue, Jan 28, 2014 at 7:21 PM, Greg Hudson <ghudson at mit.edu> wrote:
> > [1]
> > http://jtlayton.wordpress.com/2014/01/07/file-private-posix-locks-aka-un-posix-locks/
> 
> That's very nice.  A few questions (I hope Simo or others can relay to
> the relevant engineers):
> 
>  - Do private locks share the same namespace as POSIX file locks?
> Surely they must, for many reasons, among others that otherwise NFS
> will not support private locks for many, many years.
> 

Yes. The only real difference is their "ownership". Whereas classic
POSIX locks are "owned" by the process, file-private locks are "owned"
by the open file table entry (like flock() locks are).

>  - What is to be returned in the l_pid field of struct flock when
> using F_GETLKP?
> 
>    My advice: put in a constant, say, (pid_t)-1.
> 

That's exactly what it does. FWIW, the precedent comes from BSD where
flock and fcntl locks work in the same namespace.

>  - The blog says that private locks "are owned by the open file".
> Does this carry through to dup()/dup2()/...?
> 

A dup'ed fd basically just takes a reference on the instance of an open
file and assigns that to a new "slot" in the fd table for the process.
The upshot is that locks taken on dup'ed fd's won't conflict with locks
on the "original" fd.

>    Also, what if the same file is opened through several distinct
> open()s in the same process?
> 

Then those locks taken will conflict with one another since those are
distinct instances of an open file. Again, these are basically BSD
lock semantics which is what we're emulating here.

The basic idea is to have a flavor of POSIX locks that operates in the
same "lockspace" as them, but has the semantics of flock() locks on
inheritance and close.

>    My guess: it doesn't matter, just explicitly drop locks rather than
> close(2) to drop locks.  But this should be specified, even if to say
> that this is undefined.
> 

Agreed. The semantics will be explicitly documented before I'm done. I
intend not to leave much in the way of undefined corners since those
tend to be painful over the long run.

Naturally, the documentation is turning out to be the hardest part ;)

-- 
Jeff Layton <jlayton at redhat.com>