* [PATCH] locks: require that flock->l_pid be set to 0 for file-private locks
@ 2014-03-04 19:09 Jeff Layton
2014-03-04 19:22 ` J. Bruce Fields
0 siblings, 1 reply; 3+ messages in thread
From: Jeff Layton @ 2014-03-04 19:09 UTC (permalink / raw)
To: linux-fsdevel; +Cc: bfields, neilb
Neil Brown suggested potentially overloading the l_pid value as a "lock
context" field for file-private locks. While I don't think we will
probably want to do that here, it's probably a good idea to ensure that
in the future we could extend this API without breaking existing
callers.
Typically the l_pid value is ignored for incoming struct flock
arguments, serving mainly as a place to return the pid of the owner if
there is a conflicting lock. For file-private locks, require that it
currently be set to 0 and return EINVAL if it isn't. If we eventually
want to make a non-zero l_pid mean something, then this will help ensure
that we don't break legacy programs that are using file-private locks.
Cc: Neil Brown <neilb@suse.de>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
---
fs/locks.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/fs/locks.c b/fs/locks.c
index ce93815b0626..6fdf26a79cc8 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1931,6 +1931,10 @@ int fcntl_getlk(struct file *filp, unsigned int cmd, struct flock __user *l)
goto out;
if (cmd == F_GETLKP) {
+ error = -EINVAL;
+ if (flock.l_pid != 0)
+ goto out;
+
cmd = F_GETLK;
file_lock.fl_flags |= FL_FILE_PVT;
file_lock.fl_owner = (fl_owner_t)filp;
@@ -2062,11 +2066,19 @@ again:
*/
switch (cmd) {
case F_SETLKP:
+ error = -EINVAL;
+ if (flock.l_pid != 0)
+ goto out;
+
cmd = F_SETLK;
file_lock->fl_flags |= FL_FILE_PVT;
file_lock->fl_owner = (fl_owner_t)filp;
break;
case F_SETLKPW:
+ error = -EINVAL;
+ if (flock.l_pid != 0)
+ goto out;
+
cmd = F_SETLKW;
file_lock->fl_flags |= FL_FILE_PVT;
file_lock->fl_owner = (fl_owner_t)filp;
@@ -2121,6 +2133,10 @@ int fcntl_getlk64(struct file *filp, unsigned int cmd, struct flock64 __user *l)
goto out;
if (cmd == F_GETLKP) {
+ error = -EINVAL;
+ if (flock.l_pid != 0)
+ goto out;
+
cmd = F_GETLK64;
file_lock.fl_flags |= FL_FILE_PVT;
file_lock.fl_owner = (fl_owner_t)filp;
@@ -2185,11 +2201,19 @@ again:
*/
switch (cmd) {
case F_SETLKP:
+ error = -EINVAL;
+ if (flock.l_pid != 0)
+ goto out;
+
cmd = F_SETLK64;
file_lock->fl_flags |= FL_FILE_PVT;
file_lock->fl_owner = (fl_owner_t)filp;
break;
case F_SETLKPW:
+ error = -EINVAL;
+ if (flock.l_pid != 0)
+ goto out;
+
cmd = F_SETLKW64;
file_lock->fl_flags |= FL_FILE_PVT;
file_lock->fl_owner = (fl_owner_t)filp;
--
1.8.5.3
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH] locks: require that flock->l_pid be set to 0 for file-private locks
2014-03-04 19:09 [PATCH] locks: require that flock->l_pid be set to 0 for file-private locks Jeff Layton
@ 2014-03-04 19:22 ` J. Bruce Fields
2014-03-04 20:00 ` Jeff Layton
0 siblings, 1 reply; 3+ messages in thread
From: J. Bruce Fields @ 2014-03-04 19:22 UTC (permalink / raw)
To: Jeff Layton; +Cc: linux-fsdevel, neilb
On Tue, Mar 04, 2014 at 02:09:08PM -0500, Jeff Layton wrote:
> Neil Brown suggested potentially overloading the l_pid value as a "lock
> context" field for file-private locks. While I don't think we will
> probably want to do that here, it's probably a good idea to ensure that
> in the future we could extend this API without breaking existing
> callers.
>
> Typically the l_pid value is ignored for incoming struct flock
> arguments, serving mainly as a place to return the pid of the owner if
> there is a conflicting lock. For file-private locks, require that it
> currently be set to 0 and return EINVAL if it isn't. If we eventually
> want to make a non-zero l_pid mean something, then this will help ensure
> that we don't break legacy programs that are using file-private locks.
Makes sense to me.
But, could you add move most of this initialization to a helper
function? Or, better, just add it to flock64_to_posix_lock? That would
a) remove some code duplication, and b) give a single place to add a
comment documenting the above rationale for the new check.
--b.
>
> Cc: Neil Brown <neilb@suse.de>
> Signed-off-by: Jeff Layton <jlayton@redhat.com>
> ---
> fs/locks.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/fs/locks.c b/fs/locks.c
> index ce93815b0626..6fdf26a79cc8 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -1931,6 +1931,10 @@ int fcntl_getlk(struct file *filp, unsigned int cmd, struct flock __user *l)
> goto out;
>
> if (cmd == F_GETLKP) {
> + error = -EINVAL;
> + if (flock.l_pid != 0)
> + goto out;
> +
> cmd = F_GETLK;
> file_lock.fl_flags |= FL_FILE_PVT;
> file_lock.fl_owner = (fl_owner_t)filp;
> @@ -2062,11 +2066,19 @@ again:
> */
> switch (cmd) {
> case F_SETLKP:
> + error = -EINVAL;
> + if (flock.l_pid != 0)
> + goto out;
> +
> cmd = F_SETLK;
> file_lock->fl_flags |= FL_FILE_PVT;
> file_lock->fl_owner = (fl_owner_t)filp;
> break;
> case F_SETLKPW:
> + error = -EINVAL;
> + if (flock.l_pid != 0)
> + goto out;
> +
> cmd = F_SETLKW;
> file_lock->fl_flags |= FL_FILE_PVT;
> file_lock->fl_owner = (fl_owner_t)filp;
> @@ -2121,6 +2133,10 @@ int fcntl_getlk64(struct file *filp, unsigned int cmd, struct flock64 __user *l)
> goto out;
>
> if (cmd == F_GETLKP) {
> + error = -EINVAL;
> + if (flock.l_pid != 0)
> + goto out;
> +
> cmd = F_GETLK64;
> file_lock.fl_flags |= FL_FILE_PVT;
> file_lock.fl_owner = (fl_owner_t)filp;
> @@ -2185,11 +2201,19 @@ again:
> */
> switch (cmd) {
> case F_SETLKP:
> + error = -EINVAL;
> + if (flock.l_pid != 0)
> + goto out;
> +
> cmd = F_SETLK64;
> file_lock->fl_flags |= FL_FILE_PVT;
> file_lock->fl_owner = (fl_owner_t)filp;
> break;
> case F_SETLKPW:
> + error = -EINVAL;
> + if (flock.l_pid != 0)
> + goto out;
> +
> cmd = F_SETLKW64;
> file_lock->fl_flags |= FL_FILE_PVT;
> file_lock->fl_owner = (fl_owner_t)filp;
> --
> 1.8.5.3
>
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH] locks: require that flock->l_pid be set to 0 for file-private locks
2014-03-04 19:22 ` J. Bruce Fields
@ 2014-03-04 20:00 ` Jeff Layton
0 siblings, 0 replies; 3+ messages in thread
From: Jeff Layton @ 2014-03-04 20:00 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: linux-fsdevel, neilb
On Tue, 4 Mar 2014 14:22:12 -0500
"J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Tue, Mar 04, 2014 at 02:09:08PM -0500, Jeff Layton wrote:
> > Neil Brown suggested potentially overloading the l_pid value as a "lock
> > context" field for file-private locks. While I don't think we will
> > probably want to do that here, it's probably a good idea to ensure that
> > in the future we could extend this API without breaking existing
> > callers.
> >
> > Typically the l_pid value is ignored for incoming struct flock
> > arguments, serving mainly as a place to return the pid of the owner if
> > there is a conflicting lock. For file-private locks, require that it
> > currently be set to 0 and return EINVAL if it isn't. If we eventually
> > want to make a non-zero l_pid mean something, then this will help ensure
> > that we don't break legacy programs that are using file-private locks.
>
> Makes sense to me.
>
> But, could you add move most of this initialization to a helper
> function? Or, better, just add it to flock64_to_posix_lock? That would
> a) remove some code duplication, and b) give a single place to add a
> comment documenting the above rationale for the new check.
>
> --b.
>
Well we could consolidate it, but I don't think it'll make the patch
any smaller. We could add this to flock_to_posix_lock but you'd need to
know whether this is for a classic or file-private lock. We can't
reasonably enforce the l_pid == 0 requirement in the classic case.
So, we could do that but we'd have to start passing flock_to_posix_lock
the cmd value or a flag or something...
> >
> > Cc: Neil Brown <neilb@suse.de>
> > Signed-off-by: Jeff Layton <jlayton@redhat.com>
> > ---
> > fs/locks.c | 24 ++++++++++++++++++++++++
> > 1 file changed, 24 insertions(+)
> >
> > diff --git a/fs/locks.c b/fs/locks.c
> > index ce93815b0626..6fdf26a79cc8 100644
> > --- a/fs/locks.c
> > +++ b/fs/locks.c
> > @@ -1931,6 +1931,10 @@ int fcntl_getlk(struct file *filp, unsigned int cmd, struct flock __user *l)
> > goto out;
> >
> > if (cmd == F_GETLKP) {
> > + error = -EINVAL;
> > + if (flock.l_pid != 0)
> > + goto out;
> > +
> > cmd = F_GETLK;
> > file_lock.fl_flags |= FL_FILE_PVT;
> > file_lock.fl_owner = (fl_owner_t)filp;
> > @@ -2062,11 +2066,19 @@ again:
> > */
> > switch (cmd) {
> > case F_SETLKP:
> > + error = -EINVAL;
> > + if (flock.l_pid != 0)
> > + goto out;
> > +
> > cmd = F_SETLK;
> > file_lock->fl_flags |= FL_FILE_PVT;
> > file_lock->fl_owner = (fl_owner_t)filp;
> > break;
> > case F_SETLKPW:
> > + error = -EINVAL;
> > + if (flock.l_pid != 0)
> > + goto out;
> > +
> > cmd = F_SETLKW;
> > file_lock->fl_flags |= FL_FILE_PVT;
> > file_lock->fl_owner = (fl_owner_t)filp;
> > @@ -2121,6 +2133,10 @@ int fcntl_getlk64(struct file *filp, unsigned int cmd, struct flock64 __user *l)
> > goto out;
> >
> > if (cmd == F_GETLKP) {
> > + error = -EINVAL;
> > + if (flock.l_pid != 0)
> > + goto out;
> > +
> > cmd = F_GETLK64;
> > file_lock.fl_flags |= FL_FILE_PVT;
> > file_lock.fl_owner = (fl_owner_t)filp;
> > @@ -2185,11 +2201,19 @@ again:
> > */
> > switch (cmd) {
> > case F_SETLKP:
> > + error = -EINVAL;
> > + if (flock.l_pid != 0)
> > + goto out;
> > +
> > cmd = F_SETLK64;
> > file_lock->fl_flags |= FL_FILE_PVT;
> > file_lock->fl_owner = (fl_owner_t)filp;
> > break;
> > case F_SETLKPW:
> > + error = -EINVAL;
> > + if (flock.l_pid != 0)
> > + goto out;
> > +
> > cmd = F_SETLKW64;
> > file_lock->fl_flags |= FL_FILE_PVT;
> > file_lock->fl_owner = (fl_owner_t)filp;
> > --
> > 1.8.5.3
> >
--
Jeff Layton <jlayton@redhat.com>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-03-04 22:20 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-04 19:09 [PATCH] locks: require that flock->l_pid be set to 0 for file-private locks Jeff Layton
2014-03-04 19:22 ` J. Bruce Fields
2014-03-04 20:00 ` Jeff Layton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).