Lines Matching refs:that
7 that "inode pointer" order in the following.
20 4) rename() that is _not_ cross-directory. Locking rules: caller locks
31 * check that source is not a directory
52 The rules above obviously guarantee that all directories that are going to be
92 blocked on source and it means that it doesn't hold any locks.
95 has a child that is also contended. Indeed, suppose that it is held by
97 is blocked on belongs to child of that object due to (1).
99 It means that one of the operations is cross-directory rename.
101 would have a contended child and we had assumed that no object is its
107 would again have an infinite set of contended objects). But that
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.
120 rename() responsible for that would be holding filesystem lock and new parent
121 would have to be equal to or a descendent of source. But that means that
123 we had acquired filesystem lock and rename() would fail with -ELOOP in that
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
134 either to make sure that link(2) doesn't work for them or to make changes
135 in is_subdir() that would make it work even in presence of such beasts.