All of lore.kernel.org
 help / color / mirror / Atom feed
From: Horst Birthelmer <horst@birthelmer.de>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Horst Birthelmer <horst@birthelmer.com>,
	 Bernd Schubert <bernd@bsbernd.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	 Horst Birthelmer <hbirthelmer@ddn.com>
Subject: Re: Re: [PATCH] fuse: fix inode initialization race
Date: Thu, 26 Mar 2026 15:56:58 +0100	[thread overview]
Message-ID: <acVIc0fXasKIptC8@fedora> (raw)
In-Reply-To: <CAJfpegu9hjgwmCtM3xF6rjhY6jSvLnH+8wkr6a++RMPNDUpgWw@mail.gmail.com>

On Thu, Mar 26, 2026 at 03:51:18PM +0100, Miklos Szeredi wrote:
> On Wed, 18 Mar 2026 at 14:45, 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.
> >
> > Add a waitqueue to make fuse_reverse_inval_inode() wait when it
> > encounters an inode with attr_version == 0 (still initializing).
> > When fuse_change_attributes_common() completes initialization, it
> > wakes waiting threads.
> 
> This should be relatively rare, right?  In that case a single global
> waitq and wake_up_all() would be better, imo.

Well it depends on the use case. We send relatively many notifications
since they are bound to the DLM system and thus to changes done by a lot
of clients and so it happens that you get an invalidation while still
creating the inode.

What is wrong with one per connection?

> 
> Thanks,
> Miklos

  reply	other threads:[~2026-03-26 14:57 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-18 13:43 [PATCH] fuse: fix inode initialization race Horst Birthelmer
2026-03-25  7:54 ` Bernd Schubert
2026-03-26 14:26   ` Christian Brauner
2026-03-26 15:13     ` Bernd Schubert
2026-03-26 15:19       ` Miklos Szeredi
2026-03-26 15:45         ` Horst Birthelmer
2026-03-26 16:43           ` Joanne Koong
2026-03-26 17:54             ` Horst Birthelmer
2026-03-26 18:00               ` Joanne Koong
2026-03-26 18:11                 ` Horst Birthelmer
2026-03-26 18:37                   ` Joanne Koong
2026-03-26 18:16                 ` Bernd Schubert
2026-03-26 19:00                   ` Joanne Koong
2026-03-26 19:14                     ` Bernd Schubert
2026-03-26 14:51 ` Miklos Szeredi
2026-03-26 14:56   ` Horst Birthelmer [this message]
2026-03-26 15:06     ` Miklos Szeredi

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=acVIc0fXasKIptC8@fedora \
    --to=horst@birthelmer.de \
    --cc=bernd@bsbernd.com \
    --cc=hbirthelmer@ddn.com \
    --cc=horst@birthelmer.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.