linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Christian Brauner <brauner@kernel.org>
Cc: Eric Van Hensbergen <ericvh@gmail.com>,
	Latchesar Ionkov <lucho@ionkov.net>,
	Dominique Martinet <asmadeus@codewreck.org>,
	Christian Schoenebeck <linux_oss@crudebyte.com>,
	Joel Becker <jlbec@evilplan.org>, Christoph Hellwig <hch@lst.de>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Tejun Heo <tj@kernel.org>, Chuck Lever <chuck.lever@oracle.com>,
	Phillip Potter <phil@philpotter.co.uk>,
	v9fs-developer@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v2] fs: consolidate dt_type() helper definitions
Date: Thu, 30 Mar 2023 06:14:15 -0400	[thread overview]
Message-ID: <eba75b19eab0281f79632edc0317ea7bbda9cb58.camel@kernel.org> (raw)
In-Reply-To: <20230330-magma-struck-e1f80f624070@brauner>

On Thu, 2023-03-30 at 07:44 +0200, Christian Brauner wrote:
> 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.

Good point.

The dt_type returns are all handed to dir_emit, and it looks like most
of the readdir actor functions just take that value as-is and stuff it
into the appropriate readdir response.

Given that, we probably don't want to hand the actors any "custom"
values and should switch these callers over to fs_umode_to_dtype
instead.

I'll plan to spin up a v3 series (and address HCH's comments in that
too).

Thanks for the review, everyone!
-- 
Jeff Layton <jlayton@kernel.org>

      reply	other threads:[~2023-03-30 10:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-30  0:01 [PATCH v2] fs: consolidate dt_type() helper definitions Jeff Layton
2023-03-30  0:03 ` Christoph Hellwig
2023-03-30  5:14   ` Christian Brauner
2023-03-30  5:44 ` Christian Brauner
2023-03-30 10:14   ` Jeff Layton [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eba75b19eab0281f79632edc0317ea7bbda9cb58.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=asmadeus@codewreck.org \
    --cc=brauner@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=ericvh@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=jlbec@evilplan.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux_oss@crudebyte.com \
    --cc=lucho@ionkov.net \
    --cc=phil@philpotter.co.uk \
    --cc=tj@kernel.org \
    --cc=v9fs-developer@lists.sourceforge.net \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).