Lines Matching refs:that
12 that "inode pointer" order in the following.
25 4) rename() that is _not_ cross-directory. Locking rules: caller locks the
36 * check that source is not a directory
62 The rules above obviously guarantee that all directories that are going to be
104 blocked on source and it means that it doesn't hold any locks.
107 has a child that is also contended. Indeed, suppose that it is held by
109 is blocked on belongs to child of that object due to (1).
111 It means that one of the operations is cross-directory rename.
113 would have a contended child and we had assumed that no object is its
119 would again have an infinite set of contended objects). But that
120 means that cross-directory rename is taking locks out of order. Due
122 But locking rules for cross-directory rename guarantee that we do not
128 the only operation that could introduce loops is cross-directory rename.
132 rename() responsible for that would be holding filesystem lock and new parent
133 would have to be equal to or a descendent of source. But that means that
135 we had acquired filesystem lock and rename() would fail with -ELOOP in that
139 ability to check that directory is a descendent of another object. Current
140 implementation assumes that directory graph is a tree. This assumption is
141 also preserved by all operations (cross-directory rename on a tree that would
144 Notice that "directory" in the above == "anything that might have
146 either to make sure that link(2) doesn't work for them or to make changes
147 in is_subdir() that would make it work even in presence of such beasts.