Lines Matching refs:that

7 that "inode pointer" order in the following.
18 4) rename() that is _not_ cross-directory.  Locking rules: caller locks
20 it.  If source is a non-directory, lock it.  If that means we need to
25 	* check that source is not a directory
39 	  it.  In case that means we need to lock both source and target,
44 The rules above obviously guarantee that all directories that are going to be
84 blocked on source and it means that it doesn't hold any locks.
87 has a child that is also contended.  Indeed, suppose that it is held by
89 is blocked on belongs to child of that object due to (1).
91 	It means that one of the operations is cross-directory rename.
93 would have a contended child and we had assumed that no object is its
99 would again have an infinite set of contended objects).  But that
100 means that cross-directory rename is taking locks out of order.  Due
102 But locking rules for cross-directory rename guarantee that we do not
108 the only operation that could introduce loops is cross-directory rename.
112 rename() responsible for that would be holding filesystem lock and new parent
113 would have to be equal to or a descendent of source.  But that means that
115 we had acquired filesystem lock and rename() would fail with -ELOOP in that
119 ability to check that directory is a descendent of another object.  Current
120 implementation assumes that directory graph is a tree.  This assumption is
121 also preserved by all operations (cross-directory rename on a tree that would
124 	Notice that "directory" in the above == "anything that might have
126 either to make sure that link(2) doesn't work for them or to make changes
127 in is_subdir() that would make it work even in presence of such beasts.