Re: [PATCH v6 1/6] fuse: decouple fuse_ring creation from ent registration

On Fri, Jul 17, 2026 at 9:41=E2=80=AFAM Miklos Szeredi <[email protected]> =
wrote:
>
> On Fri, 17 Jul 2026 at 18:28, Joanne Koong <[email protected]> wrote=
:
> >
> > On Fri, Jul 17, 2026 at 2:32=E2=80=AFAM Miklos Szeredi <miklos@szeredi.=
hu> wrote:
> > >
> > > On Thu, 16 Jul 2026 at 19:59, Joanne Koong <[email protected]> w=
rote:
> > > >
> > > > Currently, the connection's fuse_ring is created lazily on the firs=
t
> > > > FUSE_IO_URING_CMD_REGISTER command. A server registers entries from=
 one
> > > > thread per queue (one per CPU) and those threads issue their first
> > > > REGISTER command concurrently. They then race to create the single
> > > > per-connection fuse_ring, which required open-coded handling in
> > > > fuse_uring_create() to detect and protect against concurrent creati=
ons.
> > > >
> > > > Decouple fuse_ring creation from ent registration and move it to
> > > > FUSE_INIT reply processing after a server has negotiated and set
> > > > FUSE_OVER_IO_URING. The ring is published before the connection is
> > > > marked initialized. fuse_uring_register() no longer creates the rin=
g and
> > > > it instead uses the ring set up at init time.
> > >
> > > What about if the fuse ring is not yet set up?  Should
> > > fuse_uring_register() wait in that case?
> >
> > The fuse ring is set up when the kernel processes the FUSE_INIT reply.
> > If userspace races ahead and issues a REGISTER before the FUSE_INIT
> > reply is processed, they get back -EAGAIN and will need to retry,
> > which is the same as the pre-existing behavior. The ring gets
> > published before fch->initialized gets set.
> >
> > Not sure if this answers your question or if I'm misreading what you're=
 asking.
>
> That was my question, yes.
>
> Retrying in a loop doesn't sound like good behavior.
>
> I was thinking that with sync INIT the completing the write() with the
> INIT reply does not mean that the connection gets initialized.
>
> Shouldn't the REGISTER op block until initialization is complete?

Yes, this would be more ideal for the sync case. libfuse currently
works around this with the retry loop.

This is a pre-existing issue that's not introduced by this series
though, so I'll send a patch out for this separately.

Thanks,
Joanne