|
@@ -349,6 +349,7 @@ fl_release_private: maybe no
|
|
|
----------------------- lock_manager_operations ---------------------------
|
|
|
prototypes:
|
|
|
int (*lm_compare_owner)(struct file_lock *, struct file_lock *);
|
|
|
+ unsigned long (*lm_owner_key)(struct file_lock *);
|
|
|
void (*lm_notify)(struct file_lock *); /* unblock callback */
|
|
|
int (*lm_grant)(struct file_lock *, struct file_lock *, int);
|
|
|
void (*lm_break)(struct file_lock *); /* break_lease callback */
|
|
@@ -358,16 +359,21 @@ 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
|
|
|
|
|
|
-[1]: ->lm_compare_owner is generally called with *an* inode->i_lock held. It
|
|
|
-may not be the i_lock of the inode for either file_lock being compared! 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. When doing a search for deadlocks, the file_lock_lock is also held.
|
|
|
+[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
|
|
|
+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.
|
|
|
|
|
|
--------------------------- buffer_head -----------------------------------
|
|
|
prototypes:
|