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>
prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.