Lines Matching +full:common +full:- +full:rules
7 kinds of locks - per-inode (->i_rwsem) and per-filesystem
8 (->s_vfs_rename_mutex).
10 When taking the i_rwsem on multiple non-directory objects, we
20 1. read access. Locking rules:
24 2. object creation. Locking rules:
28 3. object removal. Locking rules:
34 4. link creation. Locking rules:
40 5. rename that is _not_ cross-directory. Locking rules:
45 The source needs to be locked if it's a non-directory, target - if it's
46 a non-directory or about to be removed.
49 are non-directories - the source because it wouldn't need to be locked
50 otherwise and the target because mixing directory and non-directory is
53 6. cross-directory rename. The trickiest in the whole bunch. Locking rules:
56 * if the parents don't have a common ancestor, fail the operation.
63 * lock the non-directories involved (exclusive), in inode pointer order.
65 The rules above obviously guarantee that all directories that are going
72 There is one more thing to consider - splicing. It's not an operation
75 picture of those - especially for network filesystems. What we have
78 that's not a problem, but there is a nasty twist - what should we do
82 the root of another"; there's also open-by-fhandle stuff, and there's a
106 if two dentries have been found to have a common ancestor after taking
109 splicing is almost irrelevant - the only place where it matters is one
110 step in cross-directory renames; we need to be careful when checking if
111 parents have a common ancestor.
114 Multiple-filesystem stuff
121 on other filesystems must follow the same locking rules. Moreover, "a
125 on a filesystem could trigger directory operations only on higher-ranked
126 ones - in these terms overlayfs ranks lower than its layers, network
133 If no directory is its own ancestor, the scheme above is deadlock-free.
138 them in order of non-decreasing rank. Namely,
140 * rank ->i_rwsem of non-directories on given filesystem in inode pointer
142 * put ->i_rwsem of all directories on a filesystem at the same rank,
143 lower than ->i_rwsem of any non-directory on the same filesystem.
144 * put ->s_vfs_rename_mutex at rank lower than that of any ->i_rwsem
151 1. ->s_vfs_rename_mutex of NFS filesystem
152 2. ->i_rwsem of directories on that NFS filesystem, same rank for all
153 3. ->i_rwsem of non-directories on that filesystem, in order of
155 4. ->s_vfs_rename_mutex of local filesystem
156 5. ->i_rwsem of directories on the local filesystem, same rank for all
157 6. ->i_rwsem of non-directories on local filesystem, in order of
169 i.e. they all will be ->i_rwsem of directories on the same filesystem.
188 child), same-directory rename killing a subdirectory (ditto) and
189 cross-directory rename of some sort.
191 There must be a cross-directory rename in the set; indeed,
200 more than one cross-directory rename among them. Without loss of
201 generality we can assume that T1 is the one doing a cross-directory
204 In other words, we have a cross-directory rename that locked
208 cross-directory rename does not get to locking any directories until it
210 a common ancestor, which guarantees that ancestry relationships between
214 cross-directory rename; parents first, then possibly their children.
218 It can't be the parents - indeed, since D1 is an ancestor of Dn,
221 of another - otherwise the operation would not have progressed past
232 That leaves only one possibility - namely, both Dn and D1 are
239 Note that the check for having a common ancestor in cross-directory
240 rename is crucial - without it a deadlock would be possible. Indeed,
244 descendent of the parent of target. At that point we have cross-directory
247 in between (all of those would fail with -ENOTEMPTY, had they ever gotten
248 the locks) and voila - we have a deadlock.
254 the only operation that could introduce loops is cross-directory rename.
267 chains of ancestors of (ex-)parents of source and target. In particular,
271 source or target; the next node in the loop would be the ex-parent of
280 also preserved by all operations (cross-directory rename on a tree that would