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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux