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

locks: pass correct "before" pointer to locks_unlink_lock in generic_add_lease

2014-08-22T13:58:22+00:00

The argument to locks_unlink_lock can't be just any pointer to a
pointer. It must be a pointer to the fl_next field in the previous
lock in the list.

Cc:  # v3.15+
Signed-off-by: Jeff Layton 
Reviewed-by: Christoph Hellwig

locks: move locks_free_lock calls in do_fcntl_add_lease outside spinlock

2014-08-14T14:07:47+00:00

There's no need to call locks_free_lock here while still holding the
i_lock. Defer that until the lock has been dropped.

Acked-by: J. Bruce Fields 
Signed-off-by: Jeff Layton

locks: defer freeing locks in locks_delete_lock until after i_lock has been dropped

2014-08-14T14:07:47+00:00

In commit 72f98e72551fa (locks: turn lock_flocks into a spinlock), we
moved from using the BKL to a global spinlock. With this change, we lost
the ability to block in the fl_release_private operation.

This is problematic for NFS (and probably some other filesystems as
well). Add a new list_head argument to locks_delete_lock. If that
argument is non-NULL, then queue any locks that we want to free to the
list instead of freeing them.

Then, add a new locks_dispose_list function that will walk such a list
and call locks_free_lock on them after the i_lock has been dropped.

Finally, change all of the callers of locks_delete_lock to pass in a
list_head, except for lease_modify. That function can be called long
after the i_lock has been acquired. Deferring the freeing of a lease
after unlocking it in that function is non-trivial until we overhaul
some of the spinlocking in the lease code.

Currently though, no filesystem that sets fl_release_private supports
leases, so this is not currently a problem. We'll eventually want to
make the same change in the lease code, but it needs a lot more work
before we can reasonably do so.

Acked-by: J. Bruce Fields 
Signed-off-by: Jeff Layton

locks: don't reuse file_lock in __posix_lock_file

2014-08-14T14:07:47+00:00

Currently in the case where a new file lock completely replaces the old
one, we end up overwriting the existing lock with the new info. This
means that we have to call fl_release_private inside i_lock. Change the
code to instead copy the info to new_fl, insert that lock into the
correct spot and then delete the old lock. In a later patch, we'll defer
the freeing of the old lock until after the i_lock has been dropped.

Acked-by: J. Bruce Fields 
Signed-off-by: Jeff Layton

locks: don't call locks_release_private from locks_copy_lock

2014-08-11T18:24:22+00:00

All callers of locks_copy_lock pass in a brand new file_lock struct, so
there's no need to call locks_release_private on it. Replace that with
a warning that fires in the event that we receive a target lock that
doesn't look like it's properly initialized.

Acked-by: J. Bruce Fields 
Signed-off-by: Jeff Layton

locks: show delegations as "DELEG" in /proc/locks

2014-08-11T17:36:54+00:00

Now that they are a distinct lease type, show them as such.

Cc: J. Bruce Fields 
Signed-off-by: Jeff Layton

locks: purge fl_owner_t from fs/locks.c

2014-07-14T01:39:07+00:00

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

locks: set fl_owner for leases back to current->files

2014-06-10T16:29:05+00:00

This fixes a regression due to commit 130d1f956ab3 (locks: ensure that
fl_owner is always initialized properly in flock and lease codepaths). I
had mistakenly thought that the fl_owner wasn't used in the lease code,
but I missed the place in __break_lease that does use it.

The i_have_this_lease check in generic_add_lease uses it. While I'm not
sure that check is terribly helpful [1], reset it back to using
current->files in order to ensure that there's no behavior change here.

[1]: leases are owned by the file description. It's possible that this
     is a threaded program, and the lease breaker and the task that
     would handle the signal are different, even if they have the same
     file table. So, there is the potential for false positives with
     this check.

Fixes: 130d1f956ab3 (locks: ensure that fl_owner is always initialized properly in flock and lease codepaths)
Signed-off-by: Jeff Layton

locks: add some tracepoints in the lease handling code

2014-06-02T12:09:30+00:00

v2: add a __break_lease tracepoint for non-blocking case

Recently, I needed these to help track down a softlockup when recalling a
delegation, but they might be helpful in other situations as well.

Cc: "J. Bruce Fields" 
Signed-off-by: Jeff Layton

fs/locks.c: replace seq_printf by seq_puts

2014-06-02T12:09:29+00:00

Replace seq_printf where possible

Cc: Jeff Layton 
Cc: Alexander Viro 
Cc: Andrew Morton 
Signed-off-by: Fabian Frederick 
Signed-off-by: Jeff Layton