Lines Matching refs:dentry

4 Path resolution is the finding a dentry corresponding to a path name string, by
7 with the first component of the pathname (eg. root or cwd) with a known dentry,
8 then finding the child of that dentry, which is named the next component in the
9 path string. Then repeating the lookup from the child dentry and finding its
26 dentry that was looked up, so that may be used as the basis for walking the
28 because of the locks and atomic operations required for every dentry element
30 are path-walk intensive tend to do path lookups starting from a common dentry
44 the namespace. A path is represented as a (dentry, vfsmount) tuple. The name
88 Parent and name members of a dentry, as well as its membership in the dcache
89 hash, and its inode are protected by the per-dentry d_lock spinlock. A
90 reference is taken on the dentry (while the fields are verified under d_lock),
106 However when a dentry is renamed, its hash value can change, requiring it to be
109 high to wait for a grace period after removing the dentry and before inserting
110 it in the new hash bucket. So what is done is to insert the dentry into the
113 However, when the dentry's list pointers are updated to point to objects in the
119 dentry comparisons will never match. However it is fatal to miss a matching
120 dentry. So a seqlock is used to detect when a rename has occurred, and so the
129 Rename of dentry 2 may require it deleted from the above list, and inserted
170 Between deleting the dentry from the old hash list, and inserting it on the new
171 hash list, a lookup may find neither 'A' nor 'B' matching the dentry. The same
178 the dentry, stabilising it while comparing its name and parent and then
184 dentry seqlock (d_seq) is used to take a "coherent snapshot" of what the dentry
188 than reloading from the dentry later on (otherwise we'd have interesting things
198 protect the dentry object from disappearing, can perform a seqcount based
199 lookup which does not increment the refcount on the dentry or write to
200 it in any way. This returned dentry can be used for subsequent operations,
203 Inodes are also rcu freed, so the seqcount lookup dentry's inode may also be
207 locks or refcounts on dentry elements.
214 serialise concurrent modifications to the dentry and take a reference count on
216 walking is operating on each dentry. rcu-walk uses seqcount based dentry
218 shared data in the dentry or inode. rcu-walk can not be applied to all cases,
222 [*] RCU is still used for the dentry hash lookup in ref-walk, but not the full
241 start from current->fs->root, which is a pinned dentry. Alternatively,
245      dentry 0
252      dentry 1 V
267     +---------------------+   At this point we have our destination dentry.
269     | inode:   14221      |   dentry. If that checks out, we can increment
273 Taking a refcount on a dentry from rcu-walk mode, by taking its d_lock,
286 at the last known good dentry we have. Avoiding a full restart in ref-walk in
293   of the starting path (eg. root/cwd/fd-path). So now dentry refcounts are
294   not required for dentry persistence.
299   lookups, and to assume dentry mount points and mount roots are stable up and
301 * Have a per-dentry seqlock to protect the dentry name, parent, and inode,
311 * When the destination dentry is reached, drop rcu there (ie. take d_lock,
318 * NULL dentry (ie. any uncached path element)
330 refcount on final dentry.
344 element, nodentry for missing dentry, revalidate for filesystem revalidate
360 Dropping from rcu-walk to ref-walk mean that we have encountered a dentry where
364 only when we have reached the target dentry, so the other statistics show where
368 dentry not existing (which can be common) is not necessarily a failure of
371 root), the less contended the dentry is likely to be. The closer we are to
372 common path elements, the more likely they will exist in dentry cache.