summaryrefslogtreecommitdiff
path: root/Documentation/filesystems/Locking
diff options
context:
space:
mode:
authorJeff Layton <jlayton@redhat.com>2013-06-21 08:58:20 -0400
committerAl Viro <viro@zeniv.linux.org.uk>2013-06-29 12:57:46 +0400
commit7b2296afb392bc21a50f42e7c7f4b19d3fea8c6d (patch)
tree360a8f35cf75f0bbcd1b984a6348f4c9e715e159 /Documentation/filesystems/Locking
parent3999e49364193f7dbbba66e2be655fe91ba1fced (diff)
downloadlinux-next-7b2296afb392bc21a50f42e7c7f4b19d3fea8c6d.tar.gz
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>
Diffstat (limited to 'Documentation/filesystems/Locking')
-rw-r--r--Documentation/filesystems/Locking16
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.