linux-kernel - Re: [PATCH v3 10/13] docs: path-lookup: update WALK_GET, WALK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <162396910045.29912.16061031990304843868@noble.neil.brown.name>
Date:   Fri, 18 Jun 2021 08:31:40 +1000
From:   "NeilBrown" <neilb@...e.de>
To:     "Fox Chen" <foxhlchen@...il.com>
Cc:     "Fox Chen" <foxhlchen@...il.com>, corbet@....net,
        vegard.nossum@...cle.com, viro@...iv.linux.org.uk,
        rdunlap@...radead.org, grandmaster@...klimov.de,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        gregkh@...uxfoundation.org
Subject: Re: [PATCH v3 10/13] docs: path-lookup: update WALK_GET, WALK_PUT desc

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 <foxhlchen@...il.com>
> ---
>  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
> 
>