Lines Matching refs:directory

1 	Locking scheme used for directory operations is based on two
5 	When taking the i_rwsem on multiple non-directory objects, we
11 1) read access.  Locking rules: caller locks directory we are accessing.
20 4) rename() that is _not_ cross-directory.  Locking rules: caller locks
23 if the target already exists, lock it.  If the source is a non-directory,
31 	* check that source is not a directory
36 6) cross-directory rename.  The trickiest in the whole bunch.  Locking
46 	* If the target exists, lock it.  If the source is a non-directory,
56 If no directory is its own ancestor, the scheme above is deadlock-free.
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
74 (3) locks on non-directory objects are acquired only after locks on
75     directory objects, and are acquired in inode pointer order.
77     non-directory object, except renames, which take locks on source and
86 	By (3), any process holding a non-directory lock can only be
87 waiting on another non-directory lock with a larger address.  Therefore
89 non-directory objects are not included in the set of contended locks.
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.
127 ability to check that directory is a descendent of another object.  Current
128 implementation assumes that directory graph is a tree.  This assumption is
129 also preserved by all operations (cross-directory rename on a tree that would
132 	Notice that "directory" in the above == "anything that might have