Lines Matching full:that

12 that "inode pointer" order in the following.
25 4) rename() that is _not_ cross-directory.  Locking rules: caller locks
29 Take the locks that need to be taken, in inode pointer order if need
30 to take both (that can happen only when both source and target are
33 only with RENAME_EXCHANGE, and that won't be removing the target).
39 	* check that source is not a directory
62 The rules above obviously guarantee that all directories that are going to be
75 	That ordering can change.  However, the following is true:
105 blocked on source and it means that it doesn't hold any locks.
108 has a child that is also contended.  Indeed, suppose that it is held by
110 is blocked on belongs to child of that object due to (1).
112 It means that one of the operations is cross-directory rename.
114 would have a contended child and we had assumed that no object is its
120 would again have an infinite set of contended objects).  But that
121 means that cross-directory rename is taking locks out of order.  Due
123 But locking rules for cross-directory rename guarantee that we do not
129 the only operation that could introduce loops is cross-directory rename.
133 rename() responsible for that would be holding filesystem lock and new parent
134 would have to be equal to or a descendent of source.  But that means that
136 we had acquired filesystem lock and rename() would fail with -ELOOP in that
140 ability to check that directory is a descendent of another object.  Current
141 implementation assumes that directory graph is a tree.  This assumption is
142 also preserved by all operations (cross-directory rename on a tree that would
145 Notice that "directory" in the above == "anything that might have
147 either to make sure that link(2) doesn't work for them or to make changes
148 in is_subdir() that would make it work even in presence of such beasts.