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

locks: fix unlock when fcntl_setlk races with a close

2016-03-09T23:33:25+00:00

commit 7f3697e24dc3820b10f445a4a7d914fc356012d1 upstream.

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 
Fixes: c293621bbf67 (stale POSIX lock handling)
Reported-by: Dmitry Vyukov 
Signed-off-by: Jeff Layton 
Acked-by: "J. Bruce Fields" 
Signed-off-by: Greg Kroah-Hartman

locks: eliminate BUG() call when there's an unexpected lock on file close

2014-12-06T23:55:39+00:00

commit 8c3cac5e6a85f03602ffe09c44f14418699e31ec upstream.

A leftover lock on the list is surely a sign of a problem of some sort,
but it's not necessarily a reason to panic the box. Instead, just log a
warning with some info about the lock, and then delete it like we would
any other lock.

In the event that the filesystem declares a ->lock f_op, we may end up
leaking something, but that's generally preferable to an immediate
panic.

Acked-by: J. Bruce Fields 
Signed-off-by: Jeff Layton 
Cc: Markus Blank-Burian 
Signed-off-by: Greg Kroah-Hartman

locks: allow __break_lease to sleep even when break_time is 0

2014-05-13T11:32:53+00:00

commit 4991a628a789dc5954e98e79476d9808812292ec upstream.

A fl->fl_break_time of 0 has a special meaning to the lease break code
that basically means "never break the lease". knfsd uses this to ensure
that leases don't disappear out from under it.

Unfortunately, the code in __break_lease can end up passing this value
to wait_event_interruptible as a timeout, which prevents it from going
to sleep at all. This causes __break_lease to spin in a tight loop and
causes soft lockups.

Fix this by ensuring that we pass a minimum value of 1 as a timeout
instead.

Cc: J. Bruce Fields 
Reported-by: Terry Barnaby 
Signed-off-by: Jeff Layton 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

locks: missing unlock on error in generic_add_lease()

2013-11-13T12:30:53+00:00

We should unlock here before returning.

Fixes: df4e8d2c1d2b ('locks: implement delegations')
Signed-off-by: Dan Carpenter 
Signed-off-by: Al Viro

locks: implement delegations

2013-11-09T05:16:41+00:00

Implement NFSv4 delegations at the vfs level using the new FL_DELEG lock
type.

Note nfsd is the only delegation user and is only using read
delegations.  Warn on any attempt to set a write delegation for now.
We'll come back to that case later.

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

locks: introduce new FL_DELEG lock flag

2013-11-09T05:16:41+00:00

For now FL_DELEG is just a synonym for FL_LEASE.  So this patch doesn't
change behavior.

Next we'll modify break_lease to treat FL_DELEG leases differently, to
account for the fact that NFSv4 delegations should be broken in more
situations than Windows oplocks.

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

file->f_op is never NULL...

2013-10-25T03:34:54+00:00

Signed-off-by: Al Viro

locks: move file_lock_list to a set of percpu hlist_heads and convert file_lock_lock to an lglock

2013-07-08T09:36:42+00:00

The file_lock_list is only used for /proc/locks. The vastly common case
is for locks to be put onto the list and come off again, without ever
being traversed.

Help optimize for this use-case by moving to percpu hlist_head-s. At the
same time, we can make the locking less contentious by moving to an
lglock. When iterating over the lists for /proc/locks, we must take the
global lock and then iterate over each CPU's list in turn.

This change necessitates a new fl_link_cpu field to keep track of which
CPU the entry is on. On x86_64 at least, this field is placed within an
existing hole in the struct to avoid growing the size.

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

helper for reading ->d_count

2013-07-05T14:59:33+00:00

Signed-off-by: Al Viro

locks: give the blocked_hash its own spinlock

2013-06-29T08:57:46+00:00

There's no reason we have to protect the blocked_hash and file_lock_list
with the same spinlock. With the tests I have, breaking it in two gives
a barely measurable performance benefit, but it seems reasonable to make
this locking as granular as possible.

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