Skip to content

Commit 3c1be84

Browse files
foxhlchenJonathan Corbet
authored andcommitted
docs: path-lookup: update get_link() ->follow_link description
get_link() is merged into pick_link(). i_op->follow_link is replaced with i_op->get_link(). get_link() can return ERR_PTR(0) which equals NULL. Signed-off-by: Fox Chen <foxhlchen@gmail.com> Reviewed-by: NeilBrown <neilb@suse.de> Link: https://lore.kernel.org/r/20210527091618.287093-12-foxhlchen@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
1 parent de9414a commit 3c1be84

1 file changed

Lines changed: 6 additions & 7 deletions

File tree

Documentation/filesystems/path-lookup.rst

Lines changed: 6 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1136,10 +1136,10 @@ Symlinks with no final component
11361136

11371137
A pair of special-case symlinks deserve a little further explanation.
11381138
Both result in a new ``struct path`` (with mount and dentry) being set
1139-
up in the ``nameidata``, and result in ``get_link()`` returning ``NULL``.
1139+
up in the ``nameidata``, and result in ``pick_link()`` returning ``NULL``.
11401140

11411141
The more obvious case is a symlink to "``/``". All symlinks starting
1142-
with "``/``" are detected in ``get_link()`` which resets the ``nameidata``
1142+
with "``/``" are detected in ``pick_link()`` which resets the ``nameidata``
11431143
to point to the effective filesystem root. If the symlink only
11441144
contains "``/``" then there is nothing more to do, no components at all,
11451145
so ``NULL`` is returned to indicate that the symlink can be released and
@@ -1156,12 +1156,11 @@ something that looks like a symlink. It is really a reference to the
11561156
target file, not just the name of it. When you ``readlink`` these
11571157
objects you get a name that might refer to the same file - unless it
11581158
has been unlinked or mounted over. When ``walk_component()`` follows
1159-
one of these, the ``->follow_link()`` method in "procfs" doesn't return
1159+
one of these, the ``->get_link()`` method in "procfs" doesn't return
11601160
a string name, but instead calls ``nd_jump_link()`` which updates the
1161-
``nameidata`` in place to point to that target. ``->follow_link()`` then
1162-
returns ``NULL``. Again there is no final component and ``get_link()``
1163-
reports this by leaving the ``last_type`` field of ``nameidata`` as
1164-
``LAST_BIND``.
1161+
``nameidata`` in place to point to that target. ``->get_link()`` then
1162+
returns ``NULL``. Again there is no final component and ``pick_link()``
1163+
returns ``NULL``.
11651164

11661165
Following the symlink in the final component
11671166
--------------------------------------------

0 commit comments

Comments
 (0)