Documentation/filesystems/path-lookup.rst

Source file repositories/reference/linux-study-clean/Documentation/filesystems/path-lookup.rst

File Facts

System
Linux kernel
Corpus path
Documentation/filesystems/path-lookup.rst
Extension
.rst
Size
71269 bytes
Lines
1391
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

it.  If the file was found in the dcache, then ``vfs_open()`` is used for
   this.  If not, then ``lookup_open()`` will either call ``atomic_open()`` (if
   the filesystem provides it) to combine the final lookup with the open, or
   will perform the separate ``i_op->lookup()`` and ``i_op->create()`` steps
   directly.  In the later case the actual "open" of this newly found or
   created file will be performed by vfs_open(), just as if the name
   were found in the dcache.

2. vfs_open() can fail with ``-EOPENSTALE`` if the cached information
   wasn't quite current enough.  If it's in RCU-walk ``-ECHILD`` will be returned
   otherwise ``-ESTALE`` is returned.  When ``-ESTALE`` is returned, the caller may
   retry with ``LOOKUP_REVAL`` flag set.

3. An open with O_CREAT **does** follow a symlink in the final component,
   unlike other creation system calls (like ``mkdir``).  So the sequence::

          ln -s bar /tmp/foo
          echo hello > /tmp/foo

   will create a file called ``/tmp/bar``.  This is not permitted if
   ``O_EXCL`` is set but otherwise is handled for an O_CREAT open much
   like for a non-creating open: lookup_last() or open_last_lookup()
   returns a non ``NULL`` value, and link_path_walk() gets called and the
   open process continues on the symlink that was found.

Updating the access time
------------------------

We previously said of RCU-walk that it would "take no locks, increment
no counts, leave no footprints."  We have since seen that some
"footprints" can be needed when handling symlinks as a counted
reference (or even a memory allocation) may be needed.  But these
footprints are best kept to a minimum.

One other place where walking down a symlink can involve leaving
footprints in a way that doesn't affect directories is in updating access times.
In Unix (and Linux) every filesystem object has a "last accessed
time", or "``atime``".  Passing through a directory to access a file
within is not considered to be an access for the purposes of
``atime``; only listing the contents of a directory can update its ``atime``.
Symlinks are different it seems.  Both reading a symlink (with ``readlink()``)
and looking up a symlink on the way to some other destination can
update the atime on that symlink.

.. _clearest statement: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_08

It is not clear why this is the case; POSIX has little to say on the
subject.  The `clearest statement`_ is that, if a particular implementation
updates a timestamp in a place not specified by POSIX, this must be
documented "except that any changes caused by pathname resolution need
not be documented".  This seems to imply that POSIX doesn't really
care about access-time updates during pathname lookup.

.. _Linux 1.3.87: https://git.kernel.org/cgit/linux/kernel/git/history/history.git/diff/fs/ext2/symlink.c?id=f806c6db77b8eaa6e00dcfb6b567706feae8dbb8

An examination of history shows that prior to `Linux 1.3.87`_, the ext2
filesystem, at least, didn't update atime when following a link.
Unfortunately we have no record of why that behavior was changed.

In any case, access time must now be updated and that operation can be
quite complex.  Trying to stay in RCU-walk while doing it is best
avoided.  Fortunately it is often permitted to skip the ``atime``
update.  Because ``atime`` updates cause performance problems in various
areas, Linux supports the ``relatime`` mount option, which generally
limits the updates of ``atime`` to once per day on files that aren't
being changed (and symlinks never change once created).  Even without
``relatime``, many filesystems record ``atime`` with a one-second
granularity, so only one update per second is required.

It is easy to test if an ``atime`` update is needed while in RCU-walk

Annotation

Implementation Notes