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 8c4efe22e7c4 ("namei: invert the meaning of WALK_FOLLOW")
commit 1c4ff1a87e46 ("namei: invert WALK_PUT logics")
Signed-off-by: Fox Chen <[email protected]>
---
Documentation/filesystems/path-lookup.rst | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst
index 0a125673a8fe..08e6306af5b1 100644
--- a/Documentation/filesystems/path-lookup.rst
+++ b/Documentation/filesystems/path-lookup.rst
@@ -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
+forbits 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 predicates 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
2.31.1
On Thu, 27 May 2021, Fox Chen wrote:
> 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 8c4efe22e7c4 ("namei: invert the meaning of WALK_FOLLOW")
> commit 1c4ff1a87e46 ("namei: invert WALK_PUT logics")
>
> Signed-off-by: Fox Chen <[email protected]>
> ---
> Documentation/filesystems/path-lookup.rst | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst
> index 0a125673a8fe..08e6306af5b1 100644
> --- a/Documentation/filesystems/path-lookup.rst
> +++ b/Documentation/filesystems/path-lookup.rst
> @@ -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
> +forbits it from following a symlink if it finds one, ``WALK_MORE``
"forbids"
> +which indicates that it is yet too early to release the
> +current symlink, and ``WALK_TRAILING`` which predicates that it is on the final
"predicates" isn't quite the right word to use here. "indicates" is
better, but we've already used that word in the sentence, and repetition
feels clumsy (I wonder if anyone else listened to "My Word" on the BBC -
no hesitation, repetition, or deviation).
Maybe "reports"? Or maybe out chief editor can make a suggestion.
NeilBrown
> +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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> --
> 2.31.1
>
>