From: Dave Chinner <david@fromorbit.com>
To: Jan Kara <jack@suse.cz>
Cc: Mateusz Guzik <mjguzik@gmail.com>,
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 03/14] fs: provide accessors for ->i_state
Date: Wed, 15 Oct 2025 08:57:22 +1100 [thread overview]
Message-ID: <aO7HQkF8UOfjXGcd@dread.disaster.area> (raw)
In-Reply-To: <h2etb4acmmlmcvvfyh2zbwgy7bd4xeuqqyciqjw6k5zd3thmzq@vwhxpsoauli7>
On Fri, Oct 10, 2025 at 04:44:19PM +0200, Jan Kara wrote:
> On Thu 09-10-25 09:59:17, Mateusz Guzik wrote:
> > +static inline void inode_state_set_raw(struct inode *inode,
> > + enum inode_state_flags_enum flags)
> > +{
> > + WRITE_ONCE(inode->i_state, inode->i_state | flags);
> > +}
>
> I think this shouldn't really exist as it is dangerous to use and if we
> deal with XFS, nobody will actually need this function.
XFS does it's own inode caching outside the VFS, so for the moment
it needs to have access to the same VFS inode initialisation APIs as
the core VFS inode cache instantiation functions to maintain the
same externally visible behaviours.
Yes, if we change how the VFS inode caches initialise inodes, we
have to update the XFS code, but that's always been the case. This
isn't very hard to do....
Keep in mind that XFS has been caching inodes outside the VFS and
doing external state initialisation since it was first ported to
Linux (i.e. ~25 years ago). It's kinda strange to suddenly hear
people claim that this sort of VFS inode state manipulation thing is
"too dangerous" to allow anyone to use given how long we've actually
been doing this....
-Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2025-10-14 21:57 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 [this message]
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
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=aO7HQkF8UOfjXGcd@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