Lines Matching full:path

1 Path walking and name lookup locking
4 Path resolution is the finding a dentry corresponding to a path name string, by
5 performing a path walk. Typically, for every open(), stat() etc., the path name
9 path string. Then repeating the lookup from the child dentry and finding its
15 Path walking synchronisation history:
17 thus in every component during path look-up. Since 2.5.10 onwards, fast-walk
19 as many cached path component dentries as possible. This significantly
27 next path element. This is inefficient and unscalable. It is inefficient
30 are path-walk intensive tend to do path lookups starting from a common dentry
32 common path elements causes lock and cacheline queueing.
34 Since 2.6.38, RCU is used to make a significant part of the entire path walk
37 path walking.
39 Path walking overview
43 sequence of elements (directory entry names), which together refer to a path in
44 the namespace. A path is represented as a (dentry, vfsmount) tuple. The name
47 Name lookups will want to find a particular path that a name string refers to
49 the path given by the name's starting point (which we know in advance -- eg.
60 name in the name string, and require some recursive path walking.  Mount points
61 must be followed into (thus changing the vfsmount that subsequent path elements
62 refer to), switching from the mount point path to the root of the particular
64 exact path walking flags.
66 Path walking then must, broadly, do several particular things:
72 - lookup and create missing parts of the path on demand.
92 point to perform the next step of our path walk against.
180 start the next part of the path walk from).
182 As explained above, we would like to do path walking without taking locks or
183 reference counts on intermediate dentries along the path. To do this, a per
186 the next part of the path walk. When loading the coherent snapshot under d_seq,
206 With this two parts of the puzzle, we can do path lookups without taking
209 RCU-walk path walking design
212 Path walking code now has two distinct modes, ref-walk and rcu-walk. ref-walk
215 it. ref-walk is simple and obvious, and may sleep, take locks, etc while path
223     path walk.
226 path string, rcu-walk uses a d_seq protected snapshot. When looking up a
242 "./test.c" would start from cwd; both names refer to the same path in
248     | inode:   10         |   path element which is "home"...
280 the path walk must be fully restarted (which we do in ref-walk mode, to avoid
292 * Take the RCU lock for the entire path walk, starting with the acquiring
293   of the starting path (eg. root/cwd/fd-path). So now dentry refcounts are
297 * Similarly take the vfsmount lock for the entire path walk. So now mnt
300   down the path.
306   during the path walk.
309 * i_mode, i_uid, i_gid can be tested for exec permissions during path walk.
313 * If seqlock verification fails anywhere along the path, do a full restart
314   of the path lookup in ref-walk mode. -ECHILD tends to be used (for want of
318 * NULL dentry (ie. any uncached path element)
323 Uncached path elements will always require dropping to ref-walk mode, at the
327 "store-free" path walking is not strictly store free. We take vfsmount lock
334 scalability of path resolution.
342 drop rcu that fail due to d_seq failure and requiring the entire path lookup
362 we have reached the target of the path walk, or because we have encountered a
369 rcu-walk scheme, because some elements of the path may have been walked in
370 rcu-walk mode. The further we get from common path elements (such as cwd or
372 common path elements, the more likely they will exist in dentry cache.
382 3. path-lookup.md in this directory.