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

[Nico Williams]

On Wed, Jan 29, 2014 at 6:35 PM, Jeff Layton <jlayton at redhat.com> wrote:

Thanks for your reply.

>>  - 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.

Have you considered whether you might have a different struct for
getting more information about who holds it?  My opinion is that "who
holds the lock" is not trivial or possible to determine or summarize
in enough cases (most) that it's not worth doing anything else about
it.  I surmise you agree.

>>  - 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.

Because it's the same object.  That's what I expected, of course.

>>    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.

And it'd have to be so, since "the same process" is meaningless when
it's the open file reference that owns the lock, not the process that
acquired it.

> 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.

I'm a bit concerned about children processes inheriting locks by
accident then holding on to them forever.  I'm not sure what can be
done about that other than to remind people (perhaps in the fcntl(2)
man page text about private locks) to set O_CLOEXEC (or use system
calls that cause file descriptors to be born with O_CLOEXEC).

But that's a minor concern, and a price worth paying for file locking
that works.

lslk(1) might become a more useful tool though!

>>    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.

Actually, it does matter, and it has to be that distinct opens are
distinct "lock owners".  Anything else would simply not work.

> 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 ;)

Naturally.  Thanks for the response.

Nico
--