Lines Matching +full:non +full:- +full:exclusive

7 kinds of locks - per-inode (->i_rwsem) and per-filesystem
8 (->s_vfs_rename_mutex).
10 When taking the i_rwsem on multiple non-directory objects, we
20 exclusive.
23 locks victim and calls the method.  Locks are exclusive.
25 4) rename() that is _not_ cross-directory.  Locking rules: caller locks the
27 need to lock two inodes of different type (dir vs non-dir), we lock directory
29 pointer order.  Then call the method.  All locks are exclusive.
40 All locks are exclusive.
42 6) cross-directory rename.  The trickiest in the whole bunch.  Locking
50 	  fail with -ENOTEMPTY
52 	  fail with -ELOOP
54 	  need to lock two inodes of different type (dir vs non-dir), we lock
59 All ->i_rwsem are taken exclusive.  Again, we might get away with locking
66 If no directory is its own ancestor, the scheme above is deadlock-free.
71 	objects - A < B iff (A is an ancestor of B) or (B is not an ancestor
76 (1) if object removal or non-cross-directory rename holds lock on A and
78     acquire the lock on B.  (Proof: only cross-directory rename can change
81 (2) if cross-directory rename holds the lock on filesystem, order will not
82     change until rename acquires all locks.  (Proof: other cross-directory
86 (3) locks on non-directory objects are acquired only after locks on
89     non-directory object, except renames, which take locks on source and
96 Thus all processes are blocked on ->i_rwsem.
98 By (3), any process holding a non-directory lock can only be
99 waiting on another non-directory lock with a larger address.  Therefore
101 non-directory objects are not included in the set of contended locks.
103 Thus link creation can't be a part of deadlock - it can't be
106 Any contended object is either held by cross-directory rename or
108 operation other than cross-directory rename.  Then the lock this operation
111 It means that one of the operations is cross-directory rename.
112 Otherwise the set of contended objects would be infinite - each of them
114 own descendent.  Moreover, there is exactly one cross-directory rename
117 Consider the object blocking the cross-directory rename.  One
118 of its descendents is locked by cross-directory rename (otherwise we
120 means that cross-directory rename is taking locks out of order.  Due
122 But locking rules for cross-directory rename guarantee that we do not
128 the only operation that could introduce loops is cross-directory rename.
135 we had acquired filesystem lock and rename() would fail with -ELOOP in that
141 also preserved by all operations (cross-directory rename on a tree that would