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@xxxxxxxxx> > --- > 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
Attachment:
signature.asc
Description: PGP signature
