Lines Matching refs:directory

1 	Locking scheme used for directory operations is based on two
5 	When taking the i_mutex on multiple non-directory objects, we
11 1) read access.  Locking rules: caller locks directory we are accessing.
18 4) rename() that is _not_ cross-directory.  Locking rules: caller locks
20 it.  If source is a non-directory, lock it.  If that means we need to
25 	* check that source is not a directory
29 6) cross-directory rename.  The trickiest in the whole bunch.  Locking
38 	* If target exists, lock it.  If source is a non-directory, lock
48 If no directory is its own ancestor, the scheme above is deadlock-free.
56 (1) if object removal or non-cross-directory rename holds lock on A and
58     acquire the lock on B.  (Proof: only cross-directory rename can change
61 (2) if cross-directory rename holds the lock on filesystem, order will not
62     change until rename acquires all locks.  (Proof: other cross-directory
66 (3) locks on non-directory objects are acquired only after locks on
67     directory objects, and are acquired in inode pointer order.
69     non-directory object, except renames, which take locks on source and
78 	By (3), any process holding a non-directory lock can only be
79 waiting on another non-directory lock with a larger address.  Therefore
81 non-directory objects are not included in the set of contended locks.
86 	Any contended object is either held by cross-directory rename or
88 operation other than cross-directory rename.  Then the lock this operation
91 	It means that one of the operations is cross-directory rename.
94 own descendent.  Moreover, there is exactly one cross-directory rename
97 	Consider the object blocking the cross-directory rename.  One
98 of its descendents is locked by cross-directory rename (otherwise we
100 means that cross-directory rename is taking locks out of order.  Due
102 But locking rules for cross-directory rename guarantee that we do not
108 the only operation that could introduce loops is cross-directory rename.
119 ability to check that directory is a descendent of another object.  Current
120 implementation assumes that directory graph is a tree.  This assumption is
121 also preserved by all operations (cross-directory rename on a tree that would
124 	Notice that "directory" in the above == "anything that might have