From: Horst Birthelmer <horst@birthelmer.de>
To: Joanne Koong <joannelkoong@gmail.com>
Cc: Horst Birthelmer <horst@birthelmer.com>,
Miklos Szeredi <miklos@szeredi.hu>,
Bernd Schubert <bernd@bsbernd.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Horst Birthelmer <hbirthelmer@ddn.com>
Subject: Re: Re: [PATCH v2] fuse: fix inode initialization race
Date: Fri, 27 Mar 2026 18:24:43 +0100 [thread overview]
Message-ID: <aca9JlM59zH6ZldQ@fedora.fritz.box> (raw)
In-Reply-To: <CAJnrk1YuxmmkqC+J5f=YyXoFeUgYZPsURyLdkzUJPBKK+CjcFw@mail.gmail.com>
On Fri, Mar 27, 2026 at 08:40:49AM -0700, Joanne Koong wrote:
> On Fri, Mar 27, 2026 at 12:36 AM Horst Birthelmer <horst@birthelmer.com> wrote:
> >
> > From: Horst Birthelmer <hbirthelmer@ddn.com>
> >
> > Fix a race between fuse_iget() and fuse_reverse_inval_inode() where
> > invalidation can arrive while an inode is being initialized, causing
> > the invalidation to be lost.
> > By keeping the inode state I_NEW as long as the attributes are not valid
> > the invalidation can wait until the inode is fully initialized.
> >
> > Suggested-by: Joanne Koong <joannelkoong@gmail.com>
> > Signed-off-by: Horst Birthelmer <hbirthelmer@ddn.com>
> > ---
> > Changes in v2:
> > - switch from waitq guided by attr_version to wait_on_new_inode() and unlock_new_inode() when
> > the inode is fully initialized
> > - Link to v1: https://lore.kernel.org/r/20260318-fix-inode-init-race-v1-1-a7e58b2ddb9a@ddn.com
> > ---
> > fs/fuse/inode.c | 10 ++++++++--
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
> > index e57b8af06be93ecc29c58864a9c9e99c68e3283b..fa0adc2bbe58cee6f63153c60c401b78ec3695bf 100644
> > --- a/fs/fuse/inode.c
> > +++ b/fs/fuse/inode.c
> > @@ -470,6 +470,7 @@ struct inode *fuse_iget(struct super_block *sb, u64 nodeid,
> > struct inode *inode;
> > struct fuse_inode *fi;
> > struct fuse_conn *fc = get_fuse_conn_super(sb);
> > + bool is_new_inode = false;
> >
> > /*
> > * Auto mount points get their node id from the submount root, which is
> > @@ -505,13 +506,13 @@ struct inode *fuse_iget(struct super_block *sb, u64 nodeid,
> > if (!inode)
> > return NULL;
> >
> > - if ((inode_state_read_once(inode) & I_NEW)) {
> > + is_new_inode = inode_state_read_once(inode) & I_NEW;
> > + if (is_new_inode) {
> > inode->i_flags |= S_NOATIME;
> > if (!fc->writeback_cache || !S_ISREG(attr->mode))
> > inode->i_flags |= S_NOCMTIME;
> > inode->i_generation = generation;
> > fuse_init_inode(inode, attr, fc);
> > - unlock_new_inode(inode);
> > } else if (fuse_stale_inode(inode, generation, attr)) {
> > /* nodeid was reused, any I/O on the old inode should fail */
> > fuse_make_bad(inode);
> > @@ -528,6 +529,8 @@ struct inode *fuse_iget(struct super_block *sb, u64 nodeid,
> > done:
> > fuse_change_attributes_i(inode, attr, NULL, attr_valid, attr_version,
> > evict_ctr);
> > + if (is_new_inode)
> > + unlock_new_inode(inode);
> > return inode;
> > }
> >
> > @@ -565,6 +568,9 @@ int fuse_reverse_inval_inode(struct fuse_conn *fc, u64 nodeid,
> > if (!inode)
> > return -ENOENT;
> >
> > + /* Wait for inode initialization to complete */
> > + wait_on_new_inode(inode);
>
> This isn't needed.
>
> The fuse_ilookup() -> ilookup5() already waits on I_NEW.
I actually suspected that and looked for it, but did not see it in ilookup5()
Sorry about that.
>
> Thanks,
> Joanne
>
> > +
> > fi = get_fuse_inode(inode);
> > spin_lock(&fi->lock);
> > fi->attr_version = atomic64_inc_return(&fc->attr_version);
> >
> > ---
> > base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
> > change-id: 20260318-fix-inode-init-race-a47a7ba4af1e
> >
> > Best regards,
> > --
> > Horst Birthelmer <hbirthelmer@ddn.com>
> >
prev parent reply other threads:[~2026-03-27 17:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-27 7:36 [PATCH v2] fuse: fix inode initialization race Horst Birthelmer
2026-03-27 15:40 ` Joanne Koong
2026-03-27 17:24 ` Horst Birthelmer [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=aca9JlM59zH6ZldQ@fedora.fritz.box \
--to=horst@birthelmer.de \
--cc=bernd@bsbernd.com \
--cc=hbirthelmer@ddn.com \
--cc=horst@birthelmer.com \
--cc=joannelkoong@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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.