Lines Matching refs:rename

20 4) rename() that is _not_ cross-directory.  Locking rules: caller locks
36 6) cross-directory rename.  The trickiest in the whole bunch.  Locking
64 (1) if object removal or non-cross-directory rename holds lock on A and
66     acquire the lock on B.  (Proof: only cross-directory rename can change
69 (2) if cross-directory rename holds the lock on filesystem, order will not
70     change until rename acquires all locks.  (Proof: other cross-directory
94 	Any contended object is either held by cross-directory rename or
96 operation other than cross-directory rename.  Then the lock this operation
99 	It means that one of the operations is cross-directory rename.
102 own descendent.  Moreover, there is exactly one cross-directory rename
105 	Consider the object blocking the cross-directory rename.  One
106 of its descendents is locked by cross-directory rename (otherwise we
108 means that cross-directory rename is taking locks out of order.  Due
110 But locking rules for cross-directory rename guarantee that we do not
116 the only operation that could introduce loops is cross-directory rename.
117 Since the only new (parent, child) pair added by rename() is (new parent,
119 would have to exist before rename().  I.e. at the moment of loop creation
120 rename() responsible for that would be holding filesystem lock and new parent
123 we had acquired filesystem lock and rename() would fail with -ELOOP in that
129 also preserved by all operations (cross-directory rename on a tree that would