Documentation/filesystems/path-lookup.rst

52 component, but that isn't always accurate: a pathname can lack both
91 checking that the trailing slash is not used where it isn't
114 name doesn't exist in the parent.  While there can be linkage in the
129 the VFS to determine if a particular file does or doesn't exist
134 Other filesystems don't provide that guarantee because they cannot.
172 Holding a reference on a dentry ensures that the dentry won't suddenly
207 that the parent and name are correct.  So it doesn't lock the parent
267 using only ``d_lock`` locking.  If the name isn't found, then ``walk_component()``
269 the name isn't in the cache, and then calls in to the filesystem to get a
315 race.  If it hasn't been added to the primary hash table, the most
330 ``mnt_count`` doesn't ensure that the mount remains in the namespace and,
331 in particular, doesn't stabilize the link to the mounted-on dentry.  It
357 refcount on the mount itself doesn't ensure.
370 from time to time to ensure certain data structures don't get freed
414 filesystem.  Often that reference won't be needed, so this field is
449 If that doesn't get a good result, it calls "``lookup_slow()``" which
493 subsequent path traversal d_weak_revalidate() won't be called.
510 won't try to create that name.  They also check for trailing slashes
526 previously isn't really.  When this happens the lookup of the whole
569 If this flag is set, and ``d_manage()`` didn't return ``-EISDIR``,
577 If ``d_manage()`` allowed us to get this far, and ``lookup_mnt()`` didn't
625 The REF-walk mechanism already described certainly doesn't follow this
637 and carefully watching where it is, to be sure it doesn't trip.  If it
639 isn't in the cache, then it tries to stop gracefully and switch to
724 isn't necessary.  A subsequent ``read_seqcount_retry()`` will be
754 If RCU-walk finds that ``mount_lock`` hasn't changed then it can be sure
815 ``read_seqretry()`` won't validate.  In either case it will drop down to
818 Though ``rename_lock`` could be used by RCU-walk as it doesn't require
819 any sleeping, RCU-walk doesn't bother.  REF-walk uses ``rename_lock`` to
837 permission checking or name revalidation couldn't be achieved while
861 isn't sufficient if you don't actually have a counted reference at
892 dentry, so it doesn't need to worry about further consistency checks.
925 ``mount_lock`` in REF-walk.  RCU-walk doesn't make use of this pattern -
934 isn't.  Careful consideration of what exactly guarantees the safety of
965 up a path, and discarding early components is pointless as they aren't
1002 symlinks.  In many cases this will be sufficient.  If it isn't, a
1018 it doesn't need to drop down into REF-walk.
1055 but that isn't necessarily a big cost and it is better than dropping
1102 doesn't need to notice.  Getting this ``name`` variable on and off the
1149 aren't really (and are therefore commonly referred to as "magic-links")::
1159 one of these, the ``->get_link()`` method in "procfs" doesn't return
1172 ``last`` name if it doesn't exist or give an error if it does.  Other
1177 successive symlinks until one is found that doesn't point to another
1209    wasn't quite current enough.  If it's in RCU-walk ``-ECHILD`` will be returned
1235 footprints in a way that doesn't affect directories is in updating access times.
1250 not be documented".  This seems to imply that POSIX doesn't really
1256 filesystem, at least, didn't update atime when following a link.
1264 limits the updates of ``atime`` to once per day on files that aren't
1270 mode and, if it isn't, the update can be skipped and RCU-walk mode
1284 And then there is ``LOOKUP_EMPTY``, which doesn't fit conceptually with
1296 ``LOOKUP_PARENT`` indicates that the final component hasn't been reached
1301 provided by the caller, so it shouldn't be released when it is no
1358 anyway, but operations like ``stat()`` deliberately don't.  ``statfs()``
1386 than even a couple of releases ago.  But that doesn't mean it is
1389 symlinks, it doesn't help with NFS, XFS, or Btrfs.  That support