[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87pmyr11jl.fsf@notabene.neil.brown.name>
Date: Mon, 19 Apr 2021 11:54:54 +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 v2 11/12] docs: path-lookup: update get_link()
->follow_link description
On Tue, Mar 16 2021, Fox Chen wrote:
> 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@...il.com>
> ---
> Documentation/filesystems/path-lookup.rst | 13 ++++++-------
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst
> index abd0153e2415..eef6e9f68fba 100644
> --- a/Documentation/filesystems/path-lookup.rst
> +++ b/Documentation/filesystems/path-lookup.rst
> @@ -1134,10 +1134,10 @@ Symlinks with no final component
>
> A pair of special-case symlinks deserve a little further explanation.
> Both result in a new ``struct path`` (with mount and dentry) being set
> -up in the ``nameidata``, and result in ``get_link()`` returning ``NULL``.
> +up in the ``nameidata``, and result in ``pick_link()`` returning ``NULL``.
>
> The more obvious case is a symlink to "``/``". All symlinks starting
> -with "``/``" are detected in ``get_link()`` which resets the ``nameidata``
> +with "``/``" are detected in ``pick_link()`` which resets the ``nameidata``
> to point to the effective filesystem root. If the symlink only
> contains "``/``" then there is nothing more to do, no components at all,
> so ``NULL`` is returned to indicate that the symlink can be released and
> @@ -1154,12 +1154,11 @@ something that looks like a symlink. It is really a reference to the
> target file, not just the name of it. When you ``readlink`` these
> objects you get a name that might refer to the same file - unless it
> has been unlinked or mounted over. When ``walk_component()`` follows
> -one of these, the ``->follow_link()`` method in "procfs" doesn't return
> +one of these, the ``->get_link()`` method in "procfs" doesn't return
> a string name, but instead calls ``nd_jump_link()`` which updates the
> -``nameidata`` in place to point to that target. ``->follow_link()`` then
> -returns ``NULL``. Again there is no final component and ``get_link()``
> -reports this by leaving the ``last_type`` field of ``nameidata`` as
> -``LAST_BIND``.
> +``nameidata`` in place to point to that target. ``->get_link()`` then
> +returns ``0``. Again there is no final component and ``pick_link()``
Why did you change NULL to 0? ->get_link returns a pointer.
Without that change:
Reviewed-by: NeilBrown <neilb@...e.de>
Thanks,
NeilBrown
> +returns NULL.
>
> Following the symlink in the final component
> --------------------------------------------
> --
> 2.30.2
Download attachment "signature.asc" of type "application/pgp-signature" (854 bytes)
Powered by blists - more mailing lists