Lines Matching refs:directory

6 Locking scheme used for directory operations is based on two
10 When taking the i_rwsem on multiple non-directory objects, we
16 1) read access.  Locking rules: caller locks directory we are accessing.
25 4) rename() that is _not_ cross-directory.  Locking rules: caller locks
28 if the target already exists, lock it.  If the source is a non-directory,
37 	* check that source is not a directory
43 6) cross-directory rename.  The trickiest in the whole bunch.  Locking
54 	* If the target exists, lock it.  If the source is a non-directory,
65 If no directory is its own ancestor, the scheme above is deadlock-free.
74 (1) if object removal or non-cross-directory rename holds lock on A and
76     acquire the lock on B.  (Proof: only cross-directory rename can change
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
85     directory objects, and are acquired in inode pointer order.
87     non-directory object, except renames, which take locks on source and
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.
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.
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.
137 ability to check that directory is a descendent of another object.  Current
138 implementation assumes that directory graph is a tree.  This assumption is
139 also preserved by all operations (cross-directory rename on a tree that would
142 Notice that "directory" in the above == "anything that might have