From: Jan Kara <jack@suse.cz>
To: Mateusz Guzik <mjguzik@gmail.com>
Cc: Dave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.cz>,
brauner@kernel.org, viro@zeniv.linux.org.uk,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] vfs: partially sanitize i_state zeroing on inode creation
Date: Tue, 11 Jun 2024 13:40:06 +0200 [thread overview]
Message-ID: <20240611114006.swwo2o7cldvp2wyy@quack3> (raw)
In-Reply-To: <q5xcdmugfoccgu2cs5n7ku6asyaslunm2tty6r757cc2jkqjnm@g6cl4rayvxcq>
On Tue 11-06-24 13:26:45, Mateusz Guzik wrote:
> On Tue, Jun 11, 2024 at 08:56:40PM +1000, Dave Chinner wrote:
> > On Tue, Jun 11, 2024 at 12:23:59PM +0200, Mateusz Guzik wrote:
> > > I did not patch inode_init_always because it is exported and xfs uses it
> > > in 2 spots, only one of which zeroing the thing immediately after.
> > > Another one is a little more involved, it probably would not be a
> > > problem as the value is set altered later anyway, but I don't want to
> > > mess with semantics of the func if it can be easily avoided.
> >
> > Better to move the zeroing to inode_init_always(), do the basic
> > save/restore mod to xfs_reinit_inode(), and let us XFS people worry
> > about whether inode_init_always() is the right thing to be calling
> > in their code...
> >
> > All you'd need to do in xfs_reinit_inode() is this
> >
> > + unsigned long state = inode->i_state;
> >
> > .....
> > error = inode_init_always(mp->m_super, inode);
> > .....
> > + inode->i_state = state;
> > .....
> >
> > And it should behave as expected.
> >
>
> Ok, so what would be the logistics of submitting this?
>
> Can I submit one patch which includes the above + i_state moved to
> inode_init_always?
>
> Do I instead ship a two-part patchset, starting with the xfs change and
> stating it was your idea?
>
> Something else?
Well, I'd do it as 4 patches actually:
1) xfs i_state workaround in xfs_reinit_inode()
2) add i_state zeroing to inode_init_always(), drop pointless zeroing from
VFS.
3) drop now pointless zeroing from xfs
4) drop now pointless zeroing from bcachefs
This way also respective maintainers can easily ack the bits they care about.
I can live with two as you suggest since the changes are tiny but four is
IMHO a "proper" way to do things ;).
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2024-06-11 11:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-11 4:15 [PATCH] vfs: partially sanitize i_state zeroing on inode creation Mateusz Guzik
2024-06-11 10:02 ` Jan Kara
2024-06-11 10:23 ` Mateusz Guzik
2024-06-11 10:56 ` Dave Chinner
2024-06-11 11:26 ` Mateusz Guzik
2024-06-11 11:40 ` Jan Kara [this message]
2024-06-11 11:05 ` Jan Kara
2024-06-11 11:34 ` Mateusz Guzik
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=20240611114006.swwo2o7cldvp2wyy@quack3 \
--to=jack@suse.cz \
--cc=brauner@kernel.org \
--cc=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjguzik@gmail.com \
--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