[PATCH] vfs: fix docstring of hash_name()

[PATCH] vfs: fix docstring of hash_name()

[Jori Koolstra]

The docstring of hash_name() is falsely reporting that it returns the
component length, whereas it returns a pointer to the terminating '/'
or NUL character in the pathname being resolved.

Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>
---
 fs/namei.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/fs/namei.c b/fs/namei.c
index 58f715f7657e..d020b077591b 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2437,8 +2437,13 @@ u64 hashlen_string(const void *salt, const char *name)
 EXPORT_SYMBOL(hashlen_string);
 
 /*
- * Calculate the length and hash of the path component, and
- * return the length as the result.
+ * hash_name - Calculate the length and hash of the path component
+ * @nd: the path resolution state
+ * @name: the pathname to read the component from
+ * @lastword: if the component fits in a single word, the component bytes,
+ * otherwise 0
+ *
+ * Returns: a pointer to the terminating '/' or NUL character in @name.
  */
 static inline const char *hash_name(struct nameidata *nd,
 				    const char *name,
-- 
2.53.0

Re: [PATCH] vfs: fix docstring of hash_name()

[Jan Kara]

On Thu 12-03-26 12:28:22, Jori Koolstra wrote:
> The docstring of hash_name() is falsely reporting that it returns the
> component length, whereas it returns a pointer to the terminating '/'
> or NUL character in the pathname being resolved.
> 
> Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>
> ---
>  fs/namei.c | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/namei.c b/fs/namei.c
> index 58f715f7657e..d020b077591b 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -2437,8 +2437,13 @@ u64 hashlen_string(const void *salt, const char *name)
>  EXPORT_SYMBOL(hashlen_string);
>  
>  /*
> - * Calculate the length and hash of the path component, and
> - * return the length as the result.
> + * hash_name - Calculate the length and hash of the path component
> + * @nd: the path resolution state
> + * @name: the pathname to read the component from
> + * @lastword: if the component fits in a single word, the component bytes,
> + * otherwise 0

The @lastword description is what the function does but not really the
point of the parameter. I think more understandable description would be:
LAST_WORD_IS_DOT, LAST_WORD_IS_DOTDOT, or some other value depending on
whether the component is '.', '..', or something else.

Otherwise the fix looks good.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH] vfs: fix docstring of hash_name()

[Jori Koolstra]

> Op 17-03-2026 09:43 CET schreef Jan Kara <jack@suse.cz>:
> 
>  
> On Thu 12-03-26 12:28:22, Jori Koolstra wrote:
> > The docstring of hash_name() is falsely reporting that it returns the
> > component length, whereas it returns a pointer to the terminating '/'
> > or NUL character in the pathname being resolved.
> > 
> > Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>
> > ---
> >  fs/namei.c | 9 +++++++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/fs/namei.c b/fs/namei.c
> > index 58f715f7657e..d020b077591b 100644
> > --- a/fs/namei.c
> > +++ b/fs/namei.c
> > @@ -2437,8 +2437,13 @@ u64 hashlen_string(const void *salt, const char *name)
> >  EXPORT_SYMBOL(hashlen_string);
> >  
> >  /*
> > - * Calculate the length and hash of the path component, and
> > - * return the length as the result.
> > + * hash_name - Calculate the length and hash of the path component
> > + * @nd: the path resolution state
> > + * @name: the pathname to read the component from
> > + * @lastword: if the component fits in a single word, the component bytes,
> > + * otherwise 0
> 
> The @lastword description is what the function does but not really the
> point of the parameter. I think more understandable description would be:
> LAST_WORD_IS_DOT, LAST_WORD_IS_DOTDOT, or some other value depending on
> whether the component is '.', '..', or something else.
> 
> Otherwise the fix looks good.

Thanks, Jan. I incorporated your suggestion and sent it again. I really appreciate it!

> 
> 								Honza
> -- 
> Jan Kara <jack@suse.com>
> SUSE Labs, CR