From: Dave Chinner <david@fromorbit.com>
To: Mateusz Guzik <mjguzik@gmail.com>
Cc: Jan Kara <jack@suse.cz>,
brauner@kernel.org, viro@zeniv.linux.org.uk,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
josef@toxicpanda.com, kernel-team@fb.com, amir73il@gmail.com,
linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-xfs@vger.kernel.org, ceph-devel@vger.kernel.org,
linux-unionfs@vger.kernel.org
Subject: Re: [PATCH v7 13/14] xfs: use the new ->i_state accessors
Date: Wed, 15 Oct 2025 11:02:14 +1100 [thread overview]
Message-ID: <aO7khoBHdfPlEBAE@dread.disaster.area> (raw)
In-Reply-To: <CAGudoHGckJHiWN9yCngP1JMGNa1PPNvnpSuriCxSM1mwWhpBUQ@mail.gmail.com>
On Fri, Oct 10, 2025 at 05:40:49PM +0200, Mateusz Guzik wrote:
> On Fri, Oct 10, 2025 at 4:41 PM Jan Kara <jack@suse.cz> wrote:
> >
> > On Thu 09-10-25 09:59:27, Mateusz Guzik wrote:
> > > Change generated with coccinelle and fixed up by hand as appropriate.
> > >
> > > Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
> >
> > ...
> >
> > > @@ -2111,7 +2111,7 @@ xfs_rename_alloc_whiteout(
> > > */
> > > xfs_setup_iops(tmpfile);
> > > xfs_finish_inode_setup(tmpfile);
> > > - VFS_I(tmpfile)->i_state |= I_LINKABLE;
> > > + inode_state_set_raw(VFS_I(tmpfile), I_LINKABLE);
> > >
> > > *wip = tmpfile;
> > > return 0;
> > > @@ -2330,7 +2330,7 @@ xfs_rename(
> > > * flag from the inode so it doesn't accidentally get misused in
> > > * future.
> > > */
> > > - VFS_I(du_wip.ip)->i_state &= ~I_LINKABLE;
> > > + inode_state_clear_raw(VFS_I(du_wip.ip), I_LINKABLE);
> > > }
> > >
> > > out_commit:
> >
> > These two accesses look fishy (not your fault but when we are doing this
> > i_state exercise better make sure all the places are correct before
> > papering over bugs with _raw function variant). How come they cannot race
> > with other i_state modifications and thus corrupt i_state?
> >
>
> I asked about this here:
> https://lore.kernel.org/linux-xfs/CAGudoHEi05JGkTQ9PbM20D98S9fv0hTqpWRd5fWjEwkExSiVSw@mail.gmail.com/
Yes, as I said, we can add locking here if necessary, but locking
isn't necessary at this point in time because nothing else can
change the state of the newly allocated whiteout inode until we
unlock it.
Keep in mind the reason why we need I_LINKABLE here - it's not
needed for correctness - it's needed to avoid a warning embedded
in inc_nlink() because filesystems aren't trusted to implement
link counts correctly anymore.
Now we're being told that "it is too dangerous to let filesystems
manage inode state themselves" and so we have to add extra overhead
to code that we were forced to add to avoid VFS warnings added
because the VFS doesn't trust filesystems to maintain some other
important inode state....
So, if you want to get rid of XFS using I_LINKABLE here, please fix
the nlink VFS api to allow us to call inc_nlink_<something>() on a
zero link inode without I_LINKABLE needing to be set. We do actually
know what we are doing here, and as such needing I_LINKABLE here is
nothing but a hacky workaround for inflexible, trustless VFS APIs...
> > > diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
> > > index caff0125faea..ad94fbf55014 100644
> > > --- a/fs/xfs/xfs_iops.c
> > > +++ b/fs/xfs/xfs_iops.c
> > > @@ -1420,7 +1420,7 @@ xfs_setup_inode(
> > > bool is_meta = xfs_is_internal_inode(ip);
> > >
> > > inode->i_ino = ip->i_ino;
> > > - inode->i_state |= I_NEW;
> > > + inode_state_set_raw(inode, I_NEW);
"set" is wrong and will introduce a regression. This must be an
"add" operation as inode->i_state may have already been modified
by the time we get here. From 2021:
commit f38a032b165d812b0ba8378a5cd237c0888ff65f
Author: Dave Chinner <dchinner@redhat.com>
Date: Tue Aug 24 19:13:04 2021 -0700
xfs: fix I_DONTCACHE
Yup, the VFS hoist broke it, and nobody noticed. Bulkstat workloads
make it clear that it doesn't work as it should.
Fixes: dae2f8ed7992 ("fs: Lift XFS_IDONTCACHE to the VFS layer")
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c
index a3fe4c5307d3..f2210d927481 100644
--- a/fs/xfs/xfs_icache.c
+++ b/fs/xfs/xfs_icache.c
@@ -84,8 +84,9 @@ xfs_inode_alloc(
return NULL;
}
- /* VFS doesn't initialise i_mode! */
+ /* VFS doesn't initialise i_mode or i_state! */
VFS_I(ip)->i_mode = 0;
+ VFS_I(ip)->i_state = 0;
XFS_STATS_INC(mp, vn_active);
ASSERT(atomic_read(&ip->i_pincount) == 0);
diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
index 0ff0cca94092..a607d6aca5c4 100644
--- a/fs/xfs/xfs_iops.c
+++ b/fs/xfs/xfs_iops.c
@@ -1344,7 +1344,7 @@ xfs_setup_inode(
gfp_t gfp_mask;
inode->i_ino = ip->i_ino;
- inode->i_state = I_NEW;
+ inode->i_state |= I_NEW;
inode_sb_list_add(inode);
/* make the inode look hashed for the writeback code */
-Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2025-10-15 0:02 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-09 7:59 [PATCH v7 00/14] hide ->i_state behind accessors Mateusz Guzik
2025-10-09 7:59 ` [PATCH v7 01/14] fs: move wait_on_inode() from writeback.h to fs.h Mateusz Guzik
2025-10-10 13:47 ` Jan Kara
2025-10-09 7:59 ` [PATCH v7 02/14] fs: spell out fenced ->i_state accesses with explicit smp_wmb/smp_rmb Mateusz Guzik
2025-10-10 13:48 ` Jan Kara
2025-10-09 7:59 ` [PATCH v7 03/14] fs: provide accessors for ->i_state Mateusz Guzik
2025-10-10 13:51 ` Jan Kara
2025-10-10 14:44 ` Jan Kara
2025-10-10 15:51 ` Mateusz Guzik
2025-10-14 22:24 ` Dave Chinner
2025-10-15 5:46 ` Mateusz Guzik
2025-10-15 22:06 ` Dave Chinner
2025-10-20 9:43 ` Jan Kara
2025-10-14 21:57 ` Dave Chinner
2025-10-09 7:59 ` [PATCH v7 04/14] Coccinelle-based conversion to use ->i_state accessors Mateusz Guzik
2025-10-10 14:07 ` Jan Kara
2025-10-09 7:59 ` [PATCH v7 05/14] Manual conversion to use ->i_state accessors of all places not covered by coccinelle Mateusz Guzik
2025-10-10 14:10 ` Jan Kara
2025-10-09 7:59 ` [PATCH v7 06/14] btrfs: use the new ->i_state accessors Mateusz Guzik
2025-10-10 14:11 ` Jan Kara
2025-10-09 7:59 ` [PATCH v7 07/14] ceph: " Mateusz Guzik
2025-10-10 14:12 ` Jan Kara
2025-10-09 7:59 ` [PATCH v7 08/14] smb: " Mateusz Guzik
2025-10-10 14:15 ` Jan Kara
2025-10-09 7:59 ` [PATCH v7 09/14] f2fs: " Mateusz Guzik
2025-10-10 14:16 ` Jan Kara
2025-10-09 7:59 ` [PATCH v7 10/14] gfs2: " Mateusz Guzik
2025-10-10 14:17 ` Jan Kara
2025-10-09 7:59 ` [PATCH v7 11/14] overlayfs: " Mateusz Guzik
2025-10-10 14:18 ` Jan Kara
2025-10-09 7:59 ` [PATCH v7 12/14] nilfs2: " Mateusz Guzik
2025-10-10 14:18 ` Jan Kara
2025-10-09 7:59 ` [PATCH v7 13/14] xfs: " Mateusz Guzik
2025-10-10 14:41 ` Jan Kara
2025-10-10 15:40 ` Mateusz Guzik
2025-10-15 0:02 ` Dave Chinner [this message]
2025-10-15 2:10 ` Mateusz Guzik
2025-10-09 7:59 ` [PATCH v7 14/14] fs: make plain ->i_state access fail to compile Mateusz Guzik
2025-10-10 14:26 ` Jan Kara
2025-10-10 11:24 ` [PATCH v7 00/14] hide ->i_state behind accessors Christian Brauner
2025-10-10 11:29 ` Christian Brauner
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=aO7khoBHdfPlEBAE@dread.disaster.area \
--to=david@fromorbit.com \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=ceph-devel@vger.kernel.org \
--cc=jack@suse.cz \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=linux-xfs@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