Lines Matching refs:we

49 the path given by the name's starting point (which we know in advance -- eg.
55 A parent, of course, must be a directory, and we must have appropriate
79 In order to lookup a dcache (parent, name) tuple, we take a hash on the tuple
81 in that bucket is then walked, and we do a full comparison of each entry
148 However, when inserting object 2 onto a new list, we end up with this:
161 Because we didn't wait for a grace period, there may be a concurrent lookup
182 As explained above, we would like to do path walking without taking locks or
188 than reloading from the dentry later on (otherwise we'd have interesting things
192 no non-atomic stores to shared data), and to recheck the seqcount when we are
194 Avoiding destructive or changing operations means we can easily unwind from
206 With this two parts of the puzzle, we can do path lookups without taking
227 child of this parent snapshot, we open d_seq critical section on the child
246     +---------------------+   rcu-walk begins here, we note d_seq, check the
255     | inode:   678        |   string and parent pointer. When we have a match,
256     | children:"npiggin"  |   we now recheck the d_seq of dentry0. Then we
261     | name:    "npiggin"  |   not necessarily invalid, so we need only keep a
267     +---------------------+   At this point we have our destination dentry.
269     | inode:   14221      |   dentry. If that checks out, we can increment
270     | children:NULL       |   its refcount because we're holding d_lock.
278 parent snapshot fails, the house comes down, because we had closed the d_seq
279 section on the grandparent, so we have nothing left to stand on. In that case,
280 the path walk must be fully restarted (which we do in ref-walk mode, to avoid
284 When we reach a point where sleeping is required, or a filesystem callout
285 requires ref-walk, then instead of restarting the walk, we attempt to drop rcu
286 at the last known good dentry we have. Avoiding a full restart in ref-walk in
295 * synchronize_rcu is called when unregistering a filesystem, so we can
298   refcounts are not required for persistence. Also we are free to perform mount
302   so we can load this tuple atomically, and also check whether any of its
307 * inode is also RCU protected so we can load d_inode and use the inode for
328 and refcounts (both of which can be made per-cpu), and we also store to the
329 stack (which is essentially CPU-local), and we also have to take locks and
360 Dropping from rcu-walk to ref-walk mean that we have encountered a dentry where
362 we have reached the target of the path walk, or because we have encountered a
363 condition that can't be resolved in rcu-walk mode.  Ideally, we drop rcu-walk
364 only when we have reached the target dentry, so the other statistics show where
370 rcu-walk mode. The further we get from common path elements (such as cwd or
371 root), the less contended the dentry is likely to be. The closer we are to