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 the
26 parent and finds source and target.  We lock both (provided they exist).  If we
27 need to lock two inodes of different type (dir vs non-dir), we lock directory
35 	* lock parent
42 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 	  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
63 read, modified or removed by method will be locked by caller.
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
77     attempts to acquire lock on B, A will remain the parent of B until we
78     acquire the lock on B.  (Proof: only cross-directory rename can change
79     the parent of object and it would have to lock the parent).
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.
129 Since the only new (parent, child) pair added by rename() is (new parent,
132 rename() responsible for that would be holding filesystem lock and new parent
134 new parent had been equal to or a descendent of source since the moment when
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