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

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 <[email protected]=
> wrote:
> >
> > On Thu, 16 Jul 2026 at 19:59, Joanne Koong <[email protected]> wro=
te:
> > >
> > > Currently, the connection's fuse_ring is created lazily on the first
> > > FUSE_IO_URING_CMD_REGISTER command. A server registers entries from o=
ne
> > > 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 creation=
s.
> > >
> > > 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 ring =
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 a=
sking.

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?

Thanks,
Miklos