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

On Fri, Jul 17, 2026 at 10:53=E2=80=AFAM Joanne Koong <[email protected]=
om> wrote:
>
> 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]> wro=
te:
> > >
> > > On Fri, Jul 17, 2026 at 2:32=E2=80=AFAM Miklos Szeredi <miklos@szered=
i.hu> wrote:
> > > >
> > > > On Thu, 16 Jul 2026 at 19:59, Joanne Koong <[email protected]>=
 wrote:
> > > > >
> > > > > Currently, the connection's fuse_ring is created lazily on the fi=
rst
> > > > > FUSE_IO_URING_CMD_REGISTER command. A server registers entries fr=
om one
> > > > > thread per queue (one per CPU) and those threads issue their firs=
t
> > > > > REGISTER command concurrently. They then race to create the singl=
e
> > > > > per-connection fuse_ring, which required open-coded handling in
> > > > > fuse_uring_create() to detect and protect against concurrent crea=
tions.
> > > > >
> > > > > 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 i=
s
> > > > > marked initialized. fuse_uring_register() no longer creates the r=
ing 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.

We can fix up libfuse [1] to no longer send REGISTER before the
connection is initialized, so I don't think a kernel fix is strictly
needed here, but if you still prefer kernel code to coordinate this, I
can send that out.

Thanks,
Joanne

[1] https://github.com/libfuse/libfuse/pull/1561