Mailing List Archive

[PATCH 01/12] docs: path-lookup: update follow_managed() part
No follow_managed() anymore, handle_mounts(),
traverse_mounts(), will do the job.
see commit: 9deed3ebca244663530782631834e706a86a8c8f

Signed-off-by: Fox Chen <foxhlchen@gmail.com>
---
Documentation/filesystems/path-lookup.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst
index c482e1619e77..e778db767120 100644
--- a/Documentation/filesystems/path-lookup.rst
+++ b/Documentation/filesystems/path-lookup.rst
@@ -448,8 +448,8 @@ described. If it finds a ``LAST_NORM`` component it first calls
filesystem to revalidate the result if it is that sort of filesystem.
If that doesn't get a good result, it calls "``lookup_slow()``" which
takes ``i_rwsem``, rechecks the cache, and then asks the filesystem
-to find a definitive answer. Each of these will call
-``follow_managed()`` (as described below) to handle any mount points.
+to find a definitive answer. In ``step_into()``, ``handle_mount()`` will be
+called to handle any mount point.

In the absence of symbolic links, ``walk_component()`` creates a new
``struct path`` containing a counted reference to the new dentry and a
@@ -536,7 +536,7 @@ tree, but a few notes specifically related to path lookup are in order
here.

The Linux VFS has a concept of "managed" dentries which is reflected
-in function names such as "``follow_managed()``". There are three
+in function names such as "``traverse_mounts()``". There are three
potentially interesting things about these dentries corresponding
to three different flags that might be set in ``dentry->d_flags``:

--
2.30.0
Re: [PATCH 01/12] docs: path-lookup: update follow_managed() part [ In reply to ]
On Tue, Jan 26, 2021 at 03:24:32PM +0800, Fox Chen wrote:
> No follow_managed() anymore, handle_mounts(),
> traverse_mounts(), will do the job.
> see commit: 9deed3ebca244663530782631834e706a86a8c8f

When referencing commits in changelogs, please use the documented way,
which for this one would be 9deed3ebca24 ("new helper:
traverse_mounts()"). That enables us to read and understand them
better.

thanks,

greg k-h
Re: [PATCH 01/12] docs: path-lookup: update follow_managed() part [ In reply to ]
On Tue, Jan 26, 2021 at 10:03 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Jan 26, 2021 at 03:24:32PM +0800, Fox Chen wrote:
> > No follow_managed() anymore, handle_mounts(),
> > traverse_mounts(), will do the job.
> > see commit: 9deed3ebca244663530782631834e706a86a8c8f
>
> When referencing commits in changelogs, please use the documented way,
> which for this one would be 9deed3ebca24 ("new helper:
> traverse_mounts()"). That enables us to read and understand them
> better.
>
> thanks,
>
> greg k-h

Got it, I will wait to see any other things that need to be changed,
then send in v2 together.


thanks,
fox
Re: [PATCH 01/12] docs: path-lookup: update follow_managed() part [ In reply to ]
On Tue, Jan 26 2021, Fox Chen wrote:

> No follow_managed() anymore, handle_mounts(),
> traverse_mounts(), will do the job.
> see commit: 9deed3ebca244663530782631834e706a86a8c8f
>
> Signed-off-by: Fox Chen <foxhlchen@gmail.com>
> ---
> Documentation/filesystems/path-lookup.rst | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst
> index c482e1619e77..e778db767120 100644
> --- a/Documentation/filesystems/path-lookup.rst
> +++ b/Documentation/filesystems/path-lookup.rst
> @@ -448,8 +448,8 @@ described. If it finds a ``LAST_NORM`` component it first calls
> filesystem to revalidate the result if it is that sort of filesystem.
> If that doesn't get a good result, it calls "``lookup_slow()``" which
> takes ``i_rwsem``, rechecks the cache, and then asks the filesystem
> -to find a definitive answer. Each of these will call
> -``follow_managed()`` (as described below) to handle any mount points.
> +to find a definitive answer. In ``step_into()``, ``handle_mount()`` will be
> +called to handle any mount point.

The text now introduces step_into() without any hint as to why that is
relevant at this point.
It is a bit awkward to explain succinctly because while lookup_fast and
lookup_slow return a dentry which is passed to step_into(), handle_dots()
calls step_into() itself.

This is a general problem with this sort of documentation. It weaves a
story and when the code changes, you might need to completely re-weave
the story.

I don't have a good suggestion for how to fix this text, but at the
least it needs to be made clear the walk_component() calls step_into(),
either directly or via handle_dots().

>
> In the absence of symbolic links, ``walk_component()`` creates a new
> ``struct path`` containing a counted reference to the new dentry and a
> @@ -536,7 +536,7 @@ tree, but a few notes specifically related to path lookup are in order
> here.
>
> The Linux VFS has a concept of "managed" dentries which is reflected
> -in function names such as "``follow_managed()``". There are three
> +in function names such as "``traverse_mounts()``". There are three

Here you've completely broken the story. Saying

The VFS has a concept of "managed" dentries which is reflected in
function names like "traverse_mounts()"

makes no sense at all.
Again, I cannot offer any quick fix.

NeilBrown


> potentially interesting things about these dentries corresponding
> to three different flags that might be set in ``dentry->d_flags``:
>
> --
> 2.30.0