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

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

locks: consolidate NULL i_flctx checks in locks_remove_file

2015-01-16T21:08:50+00:00

We have each of the locks_remove_* variants doing this individually.
Have the caller do it instead, and have locks_remove_flock and
locks_remove_lease just assume that it's a valid pointer.

Signed-off-by: Jeff Layton

locks: keep a count of locks on the flctx lists

2015-01-16T21:08:50+00:00

This makes things a bit more efficient in the cifs and ceph lock
pushing code.

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

locks: clean up the lm_change prototype

2015-01-16T21:08:50+00:00

Now that we use standard list_heads for tracking leases, we can have
lm_change take a pointer to the lease to be modified instead of a
double pointer.

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