Re: [PATCH v2] fs: consolidate dt_type() helper definitions

[Christian Brauner <brauner@kernel.org>]

On Wed, Mar 29, 2023 at 08:01:55PM -0400, Jeff Layton wrote:
> There are 4 functions named dt_type() in the kernel. There is also the
> S_DT macro in fs_types.h.
> 
> Replace the S_DT macro with a static inline named dt_type, and have all
> of the existing copies call that instead. The v9fs helper is renamed to
> distinguish it from the others.
> 
> Cc: Chuck Lever <chuck.lever@oracle.com>
> Cc: Phillip Potter <phil@philpotter.co.uk>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
>  fs/9p/vfs_dir.c          | 6 +++---
>  fs/configfs/dir.c        | 8 +-------
>  fs/fs_types.c            | 2 +-
>  fs/kernfs/dir.c          | 8 +-------
>  fs/libfs.c               | 9 ++-------
>  include/linux/fs_types.h | 7 ++++++-
>  6 files changed, 14 insertions(+), 26 deletions(-)
> 
> What about this one instead? This consolidates another copy and we use
> Phillip's version that uses named constants instead of magic numbers.
> 
> There are some scary warnings in fs_types.h about not changing the
> definitions, but hopefully the rename from S_DT() to dt_type() is OK.
> 
> diff --git a/fs/9p/vfs_dir.c b/fs/9p/vfs_dir.c
> index 3d74b04fe0de..80b331f7f446 100644
> --- a/fs/9p/vfs_dir.c
> +++ b/fs/9p/vfs_dir.c
> @@ -41,12 +41,12 @@ struct p9_rdir {
>  };
>  
>  /**
> - * dt_type - return file type
> + * v9fs_dt_type - return file type
>   * @mistat: mistat structure
>   *
>   */
>  
> -static inline int dt_type(struct p9_wstat *mistat)
> +static inline int v9fs_dt_type(struct p9_wstat *mistat)
>  {
>  	unsigned long perm = mistat->mode;
>  	int rettype = DT_REG;
> @@ -128,7 +128,7 @@ static int v9fs_dir_readdir(struct file *file, struct dir_context *ctx)
>  			}
>  
>  			over = !dir_emit(ctx, st.name, strlen(st.name),
> -					 v9fs_qid2ino(&st.qid), dt_type(&st));
> +					 v9fs_qid2ino(&st.qid), v9fs_dt_type(&st));
>  			p9stat_free(&st);
>  			if (over)
>  				return 0;
> diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
> index 4afcbbe63e68..43863a1696eb 100644
> --- a/fs/configfs/dir.c
> +++ b/fs/configfs/dir.c
> @@ -1599,12 +1599,6 @@ static int configfs_dir_close(struct inode *inode, struct file *file)
>  	return 0;
>  }
>  
> -/* Relationship between s_mode and the DT_xxx types */
> -static inline unsigned char dt_type(struct configfs_dirent *sd)
> -{
> -	return (sd->s_mode >> 12) & 15;
> -}
> -
>  static int configfs_readdir(struct file *file, struct dir_context *ctx)
>  {
>  	struct dentry *dentry = file->f_path.dentry;
> @@ -1654,7 +1648,7 @@ static int configfs_readdir(struct file *file, struct dir_context *ctx)
>  		name = configfs_get_name(next);
>  		len = strlen(name);
>  
> -		if (!dir_emit(ctx, name, len, ino, dt_type(next)))
> +		if (!dir_emit(ctx, name, len, ino, dt_type(next->s_mode)))
>  			return 0;
>  
>  		spin_lock(&configfs_dirent_lock);
> diff --git a/fs/fs_types.c b/fs/fs_types.c
> index 78365e5dc08c..7dd5c0fb74fb 100644
> --- a/fs/fs_types.c
> +++ b/fs/fs_types.c
> @@ -76,7 +76,7 @@ static const unsigned char fs_ftype_by_dtype[DT_MAX] = {
>   */
>  unsigned char fs_umode_to_ftype(umode_t mode)
>  {
> -	return fs_ftype_by_dtype[S_DT(mode)];
> +	return fs_ftype_by_dtype[dt_type(mode)];
>  }
>  EXPORT_SYMBOL_GPL(fs_umode_to_ftype);

Nice cleanup. But looking at this a bit it makes me wonder a little. It
seems there's a bit of indirection going on:

fs_umode_to_dtype()
-> fs_type_to_dtype()
   -> fs_umode_to_ftype()
      -> fs_ftype_by_dtype()
         -> dt_type()

Presumably it exists so that unexpected return values from dt_type() are
caught and DT_UNKNOWN is returned instead of whatever raw value
dt_type() returned.

If none of the filesystems we convert to dt_type() here expects "custom"
return values from dt_type(), i.e., would never get DT_UNKNOWN, we
should consider just switching all those places to fs_umode_to_dtype().

However, if they do expect custom dt_type() values and so we really need
to have them use dt_type() then we should remove fs_umode_to_dtype()
because it is curerntly unused if my grepping skills haven't left me.