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

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]> wrote=
:
> >
> > Currently, the connection's fuse_ring is created lazily on the first
> > 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 creations.
> >
> > 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 an=
d
> > 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 ask=
ing.

Thanks,
Joanne

>
> Thanks,
> Miklos