linux-stable.git/fs/locks.c, branch v3.18.76

locks: use file_inode()

2016-07-12T12:47:18+00:00

[ Upstream commit 6343a2120862f7023006c8091ad95c1f16a32077 ]

(Another one for the f_path debacle.)

ltp fcntl33 testcase caused an Oops in selinux_file_send_sigiotask.

The reason is that generic_add_lease() used filp->f_path.dentry->inode
while all the others use file_inode().  This makes a difference for files
opened on overlayfs since the former will point to the overlay inode the
latter to the underlying inode.

So generic_add_lease() added the lease to the overlay inode and
generic_delete_lease() removed it from the underlying inode.  When the file
was released the lease remained on the overlay inode's lock list, resulting
in use after free.

Reported-by: Eryu Guan 
Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay")
Cc: 
Signed-off-by: Miklos Szeredi 
Reviewed-by: Jeff Layton 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Sasha Levin

locks: fix unlock when fcntl_setlk races with a close

2016-02-10T03:56:33+00:00

[ Upstream commit 7f3697e24dc3820b10f445a4a7d914fc356012d1 ]

Dmitry reported that he was able to reproduce the WARN_ON_ONCE that
fires in locks_free_lock_context when the flc_posix list isn't empty.

The problem turns out to be that we're basically rebuilding the
file_lock from scratch in fcntl_setlk when we discover that the setlk
has raced with a close. If the l_whence field is SEEK_CUR or SEEK_END,
then we may end up with fl_start and fl_end values that differ from
when the lock was initially set, if the file position or length of the
file has changed in the interim.

Fix this by just reusing the same lock request structure, and simply
override fl_type value with F_UNLCK as appropriate. That ensures that
we really are unlocking the lock that was initially set.

While we're there, make sure that we do pop a WARN_ON_ONCE if the
removal ever fails. Also return -EBADF in this event, since that's
what we would have returned if the close had happened earlier.

Cc: Alexander Viro 
Cc: 
Fixes: c293621bbf67 (stale POSIX lock handling)
Reported-by: Dmitry Vyukov 
Signed-off-by: Jeff Layton 
Acked-by: "J. Bruce Fields" 
Signed-off-by: Sasha Levin

locks: update comments that refer to inode->i_flock

2016-02-10T03:56:32+00:00

[ Upstream commit 8116bf4cb62d337c953cfa5369ef4cf83e73140c ]

Signed-off-by: Jeff Layton 
Signed-off-by: Sasha Levin

locks: fix NULL-deref in generic_delete_lease

2015-01-27T16:29:40+00:00

commit 52d304eb4eaced9ad04b64ba7cd6ceb5153bbf18 upstream.

commit 0efaa7e82f02fe69c05ad28e905f31fc86e6f08e
  locks: generic_delete_lease doesn't need a file_lock at all

moves the call to fl->fl_lmops->lm_change() to a place in the
code where fl might be a non-lease lock.
When that happens, fl_lmops is NULL and an Oops ensures.

So add an extra test to restore correct functioning.

Reported-by: Linda Walsh 
Link: https://bugzilla.suse.com/show_bug.cgi?id=912569
Fixes: 0efaa7e82f02fe69c05ad28e905f31fc86e6f08e
Signed-off-by: NeilBrown 
Signed-off-by: Jeff Layton 
Signed-off-by: Greg Kroah-Hartman

locks: flock_make_lock should return a struct file_lock (or PTR_ERR)

2014-10-07T18:06:13+00:00

Eliminate the need for a return pointer.

Signed-off-by: Jeff Layton 
Reviewed-by: Christoph Hellwig

locks: set fl_owner for leases to filp instead of current->files

2014-10-07T18:06:13+00:00

Like flock locks, leases are owned by the file description. Now that the
i_have_this_lease check in __break_lease is gone, we don't actually use
the fl_owner for leases for anything. So, it's now safe to set this more
appropriately to the same value as the fl_file.

While we're at it, fix up the comments over the fl_owner_t definition
since they're rather out of date.

Signed-off-by: Jeff Layton

locks: give lm_break a return value

2014-10-07T18:06:13+00:00

Christoph suggests:

   "Add a return value to lm_break so that the lock manager can tell the
    core code "you can delete this lease right now".  That gets rid of
    the games with the timeout which require all kinds of race avoidance
    code in the users."

Do that here and have the nfsd lease break routine use it when it detects
that there was a race between setting up the lease and it being broken.

Signed-off-by: Jeff Layton 
Reviewed-by: Christoph Hellwig

locks: __break_lease cleanup in preparation of allowing direct removal of leases

2014-10-07T18:06:13+00:00

Eliminate an unneeded "flock" variable. We can use "fl" as a loop cursor
everywhere. Add a any_leases_conflict helper function as well to
consolidate a bit of code.

Signed-off-by: Jeff Layton 
Reviewed-by: Christoph Hellwig

locks: remove i_have_this_lease check from __break_lease

2014-10-07T18:06:13+00:00

I think that the intent of this code was to ensure that a process won't
deadlock if it has one fd open with a lease on it and then breaks that
lease by opening another fd. In that case it'll treat the __break_lease
call as if it were non-blocking.

This seems wrong -- the process could (for instance) be multithreaded
and managing different fds via different threads. I also don't see any
mention of this limitation in the (somewhat sketchy) documentation.

Remove the check and the non-blocking behavior when i_have_this_lease
is true.

Signed-off-by: Jeff Layton

locks: move freeing of leases outside of i_lock

2014-10-07T18:06:13+00:00

There was only one place where we still could free a file_lock while
holding the i_lock -- lease_modify. Add a new list_head argument to the
lm_change operation, pass in a private list when calling it, and fix
those callers to dispose of the list once the lock has been dropped.

Signed-off-by: Jeff Layton 
Reviewed-by: Christoph Hellwig