linux-stable.git/fs/locks.c, branch v5.0

locks: fix error in locks_move_blocks()

2019-01-03T01:14:50+00:00

After moving all requests from
   fl->fl_blocked_requests
to
   new->fl_blocked_requests

it is nonsensical to do anything to all the remaining elements, there
aren't any.  This should do something to all the requests that have been
moved. For simplicity, it does it to all requests in the target list.

Setting "f->fl_blocker = new" to all members of new->fl_blocked_requests
is "obviously correct" as it preserves the invariant of the linkage
among requests.

Reported-by: syzbot+239d99847eb49ecb3899@syzkaller.appspotmail.com
Fixes: 5946c4319ebb ("fs/locks: allow a lock request to block other requests.")
Signed-off-by: NeilBrown 
Signed-off-by: Jeff Layton

locks: Use inode_is_open_for_write

2018-12-17T12:19:46+00:00

Use the aptly named function rather than open coding it. No functional
changes.

Signed-off-by: Nikolay Borisov 
Signed-off-by: Jeff Layton

fs/locks: remove unnecessary white space.

2018-12-07T11:51:00+00:00

 - spaces before tabs,
 - spaces at the end of lines,
 - multiple blank lines,
 - blank lines before EXPORT_SYMBOL,
can all go.

Signed-off-by: NeilBrown 
Reviewed-by: J. Bruce Fields 
Signed-off-by: Jeff Layton

fs/locks: merge posix_unblock_lock() and locks_delete_block()

2018-12-07T11:50:56+00:00

posix_unblock_lock() is not specific to posix locks, and behaves
nearly identically to locks_delete_block() - the former returning a
status while the later doesn't.

So discard posix_unblock_lock() and use locks_delete_block() instead,
after giving that function an appropriate return value.

Signed-off-by: NeilBrown 
Reviewed-by: J. Bruce Fields 
Signed-off-by: Jeff Layton

fs/locks: create a tree of dependent requests.

2018-12-07T11:49:24+00:00

When we find an existing lock which conflicts with a request,
and the request wants to wait, we currently add the request
to a list.  When the lock is removed, the whole list is woken.
This can cause the thundering-herd problem.
To reduce the problem, we make use of the (new) fact that
a pending request can itself have a list of blocked requests.
When we find a conflict, we look through the existing blocked requests.
If any one of them blocks the new request, the new request is attached
below that request, otherwise it is added to the list of blocked
requests, which are now known to be mutually non-conflicting.

This way, when the lock is released, only a set of non-conflicting
locks will be woken, the rest can stay asleep.
If the lock request cannot be granted and the request needs to be
requeued, all the other requests it blocks will then be woken

To make this more concrete:

  If you have a many-core machine, and have many threads all wanting to
  briefly lock a give file (udev is known to do this), you can get quite
  poor performance.

  When one thread releases a lock, it wakes up all other threads that
  are waiting (classic thundering-herd) - one will get the lock and the
  others go to sleep.
  When you have few cores, this is not very noticeable: by the time the
  4th or 5th thread gets enough CPU time to try to claim the lock, the
  earlier threads have claimed it, done what was needed, and released.
  So with few cores, many of the threads don't end up contending.
  With 50+ cores, lost of threads can get the CPU at the same time,
  and the contention can easily be measured.

  This patchset creates a tree of pending lock requests in which siblings
  don't conflict and each lock request does conflict with its parent.
  When a lock is released, only requests which don't conflict with each
  other a woken.

  Testing shows that lock-acquisitions-per-second is now fairly stable
  even as the number of contending process goes to 1000.  Without this
  patch, locks-per-second drops off steeply after a few 10s of
  processes.

  There is a small cost to this extra complexity.
  At 20 processes running a particular test on 72 cores, the lock
  acquisitions per second drops from 1.8 million to 1.4 million with
  this patch.  For 100 processes, this patch still provides 1.4 million
  while without this patch there are about 700,000.

Reported-and-tested-by: Martin Wilck 
Signed-off-by: NeilBrown 
Reviewed-by: J. Bruce Fields 
Signed-off-by: Jeff Layton

fs/locks: change all *_conflict() functions to return bool.

2018-12-07T11:49:24+00:00

posix_locks_conflict() and flock_locks_conflict() both return int.
leases_conflict() returns bool.

This inconsistency will cause problems for the next patch if not
fixed.

So change posix_locks_conflict() and flock_locks_conflict() to return
bool.
Also change the locks_conflict() helper.

And convert some
   return (foo);
to
   return foo;

Signed-off-by: NeilBrown 
Reviewed-by: J. Bruce Fields 
Signed-off-by: Jeff Layton

fs/locks: always delete_block after waiting.

2018-12-07T11:49:17+00:00

Now that requests can block other requests, we
need to be careful to always clean up those blocked
requests.
Any time that we wait for a request, we might have
other requests attached, and when we stop waiting,
we must clean them up.
If the lock was granted, the requests might have been
moved to the new lock, though when merged with a
pre-exiting lock, this might not happen.
In all cases we don't want blocked locks to remain
attached, so we remove them to be safe.

Signed-off-by: NeilBrown 
Reviewed-by: J. Bruce Fields 
Tested-by: syzbot+a4a3d526b4157113ec6a@syzkaller.appspotmail.com
Tested-by: kernel test robot 
Signed-off-by: Jeff Layton

fs/locks: allow a lock request to block other requests.

2018-11-30T16:26:12+00:00

Currently, a lock can block pending requests, but all pending
requests are equal.  If lots of pending requests are
mutually exclusive, this means they will all be woken up
and all but one will fail.  This can hurt performance.

So we will allow pending requests to block other requests.
Only the first request will be woken, and it will wake the others.

This patch doesn't implement this fully, but prepares the way.

- It acknowledges that a request might be blocking other requests,
  and when the request is converted to a lock, those blocked
  requests are moved across.
- When a request is requeued or discarded, all blocked requests are
  woken.
- When deadlock-detection looks for the lock which blocks a
  given request, we follow the chain of ->fl_blocker all
  the way to the top.

Tested-by: kernel test robot 
Signed-off-by: NeilBrown 
Reviewed-by: J. Bruce Fields 
Signed-off-by: Jeff Layton

fs/locks: use properly initialized file_lock when unlocking.

2018-11-30T16:26:12+00:00

Both locks_remove_posix() and locks_remove_flock() use a
struct file_lock without calling locks_init_lock() on it.
This means the various list_heads are not initialized, which
will become a problem with a later patch.

So change them both to initialize properly.  For flock locks,
this involves using flock_make_lock(), and changing it to
allow a file_lock to be passed in, so memory allocation isn't
always needed.

Signed-off-by: NeilBrown 
Reviewed-by: J. Bruce Fields 
Signed-off-by: Jeff Layton

fs/locks: split out __locks_wake_up_blocks().

2018-11-30T16:26:12+00:00

This functionality will be useful in future patches, so
split it out from locks_wake_up_blocks().

Signed-off-by: NeilBrown 
Reviewed-by: J. Bruce Fields 
Signed-off-by: Jeff Layton