linux.git/fs/locks.c, branch v4.0

locks: fix file_lock deletion inside loop

2015-03-27T11:18:20+00:00

locks_delete_lock_ctx() is called inside the loop, so we
should use list_for_each_entry_safe.

Fixes: 8634b51f6ca2 (locks: convert lease handling to file_lock_context)
Signed-off-by: "Yan, Zheng" 
Signed-off-by: Jeff Layton

locks: fix generic_delete_lease tracepoint to use victim pointer

2015-03-14T13:45:35+00:00

It's possible that "fl" won't point at a valid lock at this point, so
use "victim" instead which is either a valid lock or NULL.

Signed-off-by: Jeff Layton

locks: fix fasync_struct memory leak in lease upgrade/downgrade handling

2015-03-04T22:34:32+00:00

Commit 8634b51f6ca2 (locks: convert lease handling to file_lock_context)
introduced a regression in the handling of lease upgrade/downgrades.

In the event that we already have a lease on a file and are going to
either upgrade or downgrade it, we skip doing any list insertion or
deletion and simply re-call lm_setup on the existing lease.

As of commit 8634b51f6ca2 however, we end up calling lm_setup on the
lease that was passed in, instead of on the existing lease. This causes
us to leak the fasync_struct that was allocated in the event that there
was not already an existing one (as it always appeared that there
wasn't one).

Fixes: 8634b51f6ca2 (locks: convert lease handling to file_lock_context)
Reported-and-Tested-by: Daniel Wagner 
Signed-off-by: Jeff Layton

locks: fix list insertion when lock is split in two

2015-02-17T22:08:23+00:00

In the case where we're splitting a lock in two, the current code
the new "left" lock in the incorrect spot. It's inserted just
before "right" when it should instead be inserted just before the
new lock.

When we add a new lock, set "fl" to that value so that we can
add "left" before it.

Reported-by: Al Viro 
Signed-off-by: Jeff Layton

locks: remove conditional lock release in middle of flock_lock_file

2015-02-17T20:23:09+00:00

As Linus pointed out:

    Say we have an existing flock, and now do a new one that conflicts. I
    see what looks like three separate bugs.

     - We go through the first loop, find a lock of another type, and
    delete it in preparation for replacing it

     - we *drop* the lock context spinlock.

     - BUG #1? So now there is no lock at all, and somebody can come in
    and see that unlocked state. Is that really valid?

     - another thread comes in while the first thread dropped the lock
    context lock, and wants to add its own lock. It doesn't see the
    deleted or pending locks, so it just adds it

     - the first thread gets the context spinlock again, and adds the lock
    that replaced the original

     - BUG #2? So now there are *two* locks on the thing, and the next
    time you do an unlock (or when you close the file), it will only
    remove/replace the first one.

...remove the "drop the spinlock" code in the middle of this function as
it has always been suspicious. This should eliminate the potential race
that can leave two locks for the same struct file on the list.

He also pointed out another thing as a bug -- namely that you
flock_lock_file removes the lock from the list unconditionally when
doing a lock upgrade, without knowing whether it'll be able to set the
new lock. Bruce pointed out that this is expected behavior and may help
prevent certain deadlock situations.

We may want to revisit that at some point, but it's probably best that
we do so in the context of a different patchset.

Reported-by: Linus Torvalds 
Signed-off-by: Jeff Layton

locks: only remove leases associated with the file being closed

2015-02-17T20:22:57+00:00

We don't want to remove all leases just because one filp was closed.

Signed-off-by: Jeff Layton

Revert "locks: keep a count of locks on the flctx lists"

2015-02-16T19:32:03+00:00

This reverts commit 9bd0f45b7037fcfa8b575c7e27d0431d6e6dc3bb.

Linus rightly pointed out that I failed to initialize the counters
when adding them, so they don't work as expected. Just revert this
patch for now.

Reported-by: Linus Torvalds 
Signed-off-by: Jeff Layton

fs: add FL_LAYOUT lease type

2015-02-02T17:09:38+00:00

This (ab-)uses the file locking code to allow filesystems to recall
outstanding pNFS layouts on a file.  This new lease type is similar but
not quite the same as FL_DELEG.  A FL_LAYOUT lease can always be granted,
an a per-filesystem lock (XFS iolock for the initial implementation)
ensures not FL_LAYOUT leases granted when we would need to recall them.

Also included are changes that allow multiple outstanding read
leases of different types on the same file as long as they have a
differnt owner.  This wasn't a problem until now as nfsd never set
FL_LEASE leases, and no one else used FL_DELEG leases, but given that
nfsd will also issues FL_LAYOUT leases we will have to handle it now.

Signed-off-by: Christoph Hellwig

fs: track fl_owner for leases

2015-02-02T17:09:38+00:00

Just like for other lock types we should allow different owners to have
a read lease on a file.  Currently this can't happen, but with the addition
of pNFS layout leases we'll need this feature.

Signed-off-by: Christoph Hellwig

locks: update comments that refer to inode->i_flock

2015-01-22T01:44:01+00:00

Signed-off-by: Jeff Layton