Re: [RFC PATCH v2 5/5] locks: report l_pid as -1 forFL_FILP_PRIVATE locks

From: Jeff Layton
Date: Wed Nov 20 2013 - 13:55:58 EST


On Wed, 20 Nov 2013 09:55:18 -0800
"Frank Filz" <ffilzlnx@xxxxxxxxxxxxxx> wrote:

> > FL_FILP_PRIVATE locks are no longer tied to a particular PID, and are
> instead
> > inheritable by child processes. Report a l_pid of '-1' for these sorts of
> locks
> > since the pid is somewhat meaningless for them.
>
> Hmm, I suppose in the case of a process that acquires a private lock, forks
> (passing the lock to the child process) and then exits, pid would be
> meaningless, but I wonder how common that case is compared to a
> multi-threaded process (especially a file server) that will hold many
> private locks, and not pass them to child processes (and exit)?
>
> I.e. as a future user of this feature, I wonder if I'm going to want to know
> that THESE private locks are owned by Ganesha and THOSE are owned by Samba?
>
> Frank
>

A fair point.

FWIW, I took the idea of reporting '-1' from BSD, where POSIX and flock
locks can apparently conflict. If a flock lock is held on a file and
you do a F_GETLK request, then it will report '-1' for the l_pid. [1]

I sort of expect that we may need to eventually add an F_GETLK variant
that gives more info. The main reason to do this here is that we need
to put something semi-meaningful in that field for "classic" F_GETLK
users.

[1]: hmm...probably should put that in the commit log message. I'll do
that for the next respin...

> > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx>
> > ---
> > fs/locks.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/locks.c b/fs/locks.c
> > index d5fb853..8a4d4e4 100644
> > --- a/fs/locks.c
> > +++ b/fs/locks.c
> > @@ -1889,7 +1889,7 @@ EXPORT_SYMBOL_GPL(vfs_test_lock);
> >
> > static int posix_lock_to_flock(struct flock *flock, struct file_lock *fl)
> {
> > - flock->l_pid = fl->fl_pid;
> > + flock->l_pid = IS_FILP_PVT(fl) ? -1 : fl->fl_pid;
> > #if BITS_PER_LONG == 32
> > /*
> > * Make sure we can represent the posix lock via @@ -1911,7 +1911,7
> > @@ static int posix_lock_to_flock(struct flock *flock, struct file_lock
> *fl) #if
> > BITS_PER_LONG == 32 static void posix_lock_to_flock64(struct flock64
> > *flock, struct file_lock *fl) {
> > - flock->l_pid = fl->fl_pid;
> > + flock->l_pid = IS_FILP_PVT(fl) ? -1 : fl->fl_pid;
> > flock->l_start = fl->fl_start;
> > flock->l_len = fl->fl_end == OFFSET_MAX ? 0 :
> > fl->fl_end - fl->fl_start + 1;
> > --
> > 1.8.3.1
> >
> > --
> > 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
>


--
Jeff Layton <jlayton@xxxxxxxxxx>
--
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/