docs: path-lookup: update WALK_GET, WALK_PUT desc

WALK_GET is changed to WALK_TRAILING with a different meaning.
Here it should be WALK_NOFOLLOW. WALK_PUT dosn't exist, we have
WALK_MORE.

WALK_PUT == !WALK_MORE

And there is not should_follow_link().

Related commits:
commit 8c4efe22e7 ("namei: invert the meaning of WALK_FOLLOW")
commit 1c4ff1a87e ("namei: invert WALK_PUT logics")

Signed-off-by: Fox Chen <foxhlchen@gmail.com>
Reviewed-by: NeilBrown <neilb@suse.de>
[jc: applied language tweaks suggested by Neil]
Link: https://lore.kernel.org/r/20210527091618.287093-11-foxhlchen@gmail.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Fox Chen 2021-05-27 17:16:15 +08:00 committed by Jonathan Corbet
parent 18edb95a88
commit de9414adaf

View file

@ -1123,13 +1123,13 @@ stack in ``walk_component()`` immediately when the symlink is found;
old symlink as it walks that last component. So it is quite
convenient for ``walk_component()`` to release the old symlink and pop
the references just before pushing the reference information for the
new symlink. It is guided in this by two flags; ``WALK_GET``, which
gives it permission to follow a symlink if it finds one, and
``WALK_PUT``, which tells it to release the current symlink after it has been
followed. ``WALK_PUT`` is tested first, leading to a call to
``put_link()``. ``WALK_GET`` is tested subsequently (by
``should_follow_link()``) leading to a call to ``pick_link()`` which sets
up the stack frame.
new symlink. It is guided in this by three flags: ``WALK_NOFOLLOW`` which
forbids it from following a symlink if it finds one, ``WALK_MORE``
which indicates that it is yet too early to release the
current symlink, and ``WALK_TRAILING`` which indicates that it is on the final
component of the lookup, so we will check userspace flag ``LOOKUP_FOLLOW`` to
decide whether follow it when it is a symlink and call ``may_follow_link()`` to
check if we have privilege to follow it.
Symlinks with no final component
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~