locks: give the blocked_hash its own spinlock

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 <jlayton@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

1 files changed, 8 insertions, 8 deletions

diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index 2db7c9e492e9..7d9ca7a83fcc 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -357,20 +357,20 @@ prototypes:
 
 locking rules:
 
-                        inode->i_lock   file_lock_lock  may block
-lm_compare_owner:       yes[1]          maybe           no
-lm_owner_key            yes[1]          yes             no
-lm_notify:              yes             yes             no
-lm_grant:               no              no              no
-lm_break:               yes             no              no
-lm_change               yes             no              no
+                        inode->i_lock   blocked_lock_lock       may block
+lm_compare_owner:       yes[1]          maybe                   no
+lm_owner_key            yes[1]          yes                     no
+lm_notify:              yes             yes                     no
+lm_grant:               no              no                      no
+lm_break:               yes             no                      no
+lm_change               yes             no                      no
 
 [1]:    ->lm_compare_owner and ->lm_owner_key are generally called with
 *an* inode->i_lock held. It may not be the i_lock of the inode
 associated with either file_lock argument! This is the case with deadlock
 detection, since the code has to chase down the owners of locks that may
 be entirely unrelated to the one on which the lock is being acquired.
-For deadlock detection however, the file_lock_lock is also held. The
+For deadlock detection however, the blocked_lock_lock is also held. The
 fact that these locks are held ensures that the file_locks do not
 disappear out from under you while doing the comparison or generating an
 owner key.