Lines Matching +full:parent +full:- +full:locked

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
22 3) object removal.  Locking rules: caller locks parent, finds victim,
25 4) rename() that is _not_ cross-directory.  Locking rules: caller locks
26 the parent and finds source and target.  In case of exchange (with
28 if the target already exists, lock it.  If the source is a non-directory,
36 	* lock parent
43 6) cross-directory rename.  The trickiest in the whole bunch.  Locking
49 	* if old parent is equal to or is a descendent of target
50 	  fail with -ENOTEMPTY
51 	* if new parent is equal to or is a descendent of source
52 	  fail with -ELOOP
54 	* If the target exists, lock it.  If the source is a non-directory,
58 All ->i_rwsem are taken exclusive.  Again, we might get away with locking
62 read, modified or removed by method will be locked by caller.
65 If no directory is its own ancestor, the scheme above is deadlock-free.
70 	objects - A < B iff A is an ancestor of B.
74 (1) if object removal or non-cross-directory rename holds lock on A and
75     attempts to acquire lock on B, A will remain the parent of B until we
76     acquire the lock on B.  (Proof: only cross-directory rename can change
77     the parent of object and it would have to lock the parent).
79 (2) if cross-directory rename holds the lock on filesystem, order will not
80     change until rename acquires all locks.  (Proof: other cross-directory
84 (3) locks on non-directory objects are acquired only after locks on
87     non-directory object, except renames, which take locks on source and
94 Thus all processes are blocked on ->i_rwsem.
96 By (3), any process holding a non-directory lock can only be
97 waiting on another non-directory lock with a larger address.  Therefore
99 non-directory objects are not included in the set of contended locks.
101 Thus link creation can't be a part of deadlock - it can't be
104 Any contended object is either held by cross-directory rename or
106 operation other than cross-directory rename.  Then the lock this operation
109 It means that one of the operations is cross-directory rename.
110 Otherwise the set of contended objects would be infinite - each of them
112 own descendent.  Moreover, there is exactly one cross-directory rename
115 Consider the object blocking the cross-directory rename.  One
116 of its descendents is locked by cross-directory rename (otherwise we
118 means that cross-directory rename is taking locks out of order.  Due
120 But locking rules for cross-directory rename guarantee that we do not
126 the only operation that could introduce loops is cross-directory rename.
127 Since the only new (parent, child) pair added by rename() is (new parent,
130 rename() responsible for that would be holding filesystem lock and new parent
132 new parent had been equal to or a descendent of source since the moment when
133 we had acquired filesystem lock and rename() would fail with -ELOOP in that
139 also preserved by all operations (cross-directory rename on a tree that would