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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131120135745.026f468e@corrin.poochiereds.net>
Date:	Wed, 20 Nov 2013 13:57:45 -0500
From:	Jeff Layton <jlayton@...hat.com>
To:	"Frank Filz" <ffilzlnx@...dspring.com>
Cc:	<linux-fsdevel@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<nfs-ganesha-devel@...ts.sourceforge.net>,
	<samba-technical@...ts.samba.org>
Subject: Re: [RFC PATCH v2 5/5] locks: report l_pid as -1 for
 FL_FILP_PRIVATE locks

On Wed, 20 Nov 2013 09:55:18 -0800
"Frank Filz" <ffilzlnx@...dspring.com> 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@...hat.com>
> > ---
> >  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@...r.kernel.org More majordomo info at
> > http://vger.kernel.org/majordomo-info.html
> 


-- 
Jeff Layton <jlayton@...hat.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/