Re: [PATCH v3 19/25] fuse: add io-uring kernel-managed buffer ring

[Joanne Koong <joannelkoong@gmail.com>]

On Tue, Feb 3, 2026 at 3:58 PM Bernd Schubert <bernd@bsbernd.com> wrote:
>
>
>
> On 12/23/25 01:35, Joanne Koong wrote:
> > Add io-uring kernel-managed buffer ring capability for fuse daemons
> > communicating through the io-uring interface.
> >
> > This has two benefits:
> > a) eliminates the overhead of pinning/unpinning user pages and
> > translating virtual addresses for every server-kernel interaction
> >
> > b) reduces the amount of memory needed for the buffers per queue and
> > allows buffers to be reused across entries. Incremental buffer
> > consumption, when added, will allow a buffer to be used across multiple
> > requests.
> >
> > Buffer ring usage is set on a per-queue basis. In order to use this, the
> > daemon needs to have preregistered a kernel-managed buffer ring and a
> > fixed buffer at index 0 that will hold all the headers, and set the
> > "use_bufring" field during registration. The kernel-managed buffer ring
> > will be pinned for the lifetime of the connection.
> >
> > Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
> > ---
> >  fs/fuse/dev_uring.c       | 423 ++++++++++++++++++++++++++++++++------
> >  fs/fuse/dev_uring_i.h     |  30 ++-
> >  include/uapi/linux/fuse.h |  15 +-
> >  3 files changed, 399 insertions(+), 69 deletions(-)
> >
> > diff --git a/fs/fuse/dev_uring.c b/fs/fuse/dev_uring.c
> > @@ -824,21 +1040,29 @@ static void fuse_uring_add_req_to_ring_ent(struct fuse_ring_ent *ent,
> >  }
> >
> >  /* Fetch the next fuse request if available */
> > -static struct fuse_req *fuse_uring_ent_assign_req(struct fuse_ring_ent *ent)
> > +static struct fuse_req *fuse_uring_ent_assign_req(struct fuse_ring_ent *ent,
> > +                                               unsigned int issue_flags)
> >       __must_hold(&queue->lock)
> >  {
> >       struct fuse_req *req;
> >       struct fuse_ring_queue *queue = ent->queue;
> >       struct list_head *req_queue = &queue->fuse_req_queue;
> > +     int err;
> >
> >       lockdep_assert_held(&queue->lock);
> >
> >       /* get and assign the next entry while it is still holding the lock */
> >       req = list_first_entry_or_null(req_queue, struct fuse_req, list);
> > -     if (req)
> > -             fuse_uring_add_req_to_ring_ent(ent, req);
> > +     if (req) {
> > +             err = fuse_uring_next_req_update_buffer(ent, req, issue_flags);
> > +             if (!err) {
> > +                     fuse_uring_add_req_to_ring_ent(ent, req);
> > +                     return req;
> > +             }
>
> Hmm, who/what is going to handle the request if this fails? Let's say we
> have just one ring entry per queue and now it fails here - this ring
> entry will go into FRRS_AVAILABLE and nothing will pull from the queue
> anymore. I guess it _should_ not happen, some protection would be good.
> In order to handle it, at least one other ent needs to be in flight.

If the queue only has one ring ent and this fails, the request gets
reassigned to the ent whenever ->send_req() is next triggered. I don't
think this is a new edge case introduced by kmbufs; in the existing
code, fuse_uring_commit_fetch() -> fuse_uring_get_next_fuse_req() ->
fuse_uring_send_next_to_ring() -> fuse_uring_prepare_send() could fail
if any of the copying fails, in which case we end up in the same
position of the ent getting assigned the next request whenever
->send_req() is next triggered.

Thanks,
Joanne

>
> Thanks,
> Bernd