Lines Matching refs:that

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