Re: [PATCH v3 10/25] io_uring/kbuf: export io_ring_buffer_select()

[Caleb Sander Mateos <csander@purestorage.com>]

On Thu, Jan 8, 2026 at 4:38 PM Joanne Koong <joannelkoong@gmail.com> wrote:
>
> On Thu, Jan 8, 2026 at 12:34 PM Caleb Sander Mateos
> <csander@purestorage.com> wrote:
> >
> > On Mon, Dec 22, 2025 at 4:36 PM Joanne Koong <joannelkoong@gmail.com> wrote:
> > >
> > > Export io_ring_buffer_select() so that it may be used by callers who
> > > pass in a pinned bufring without needing to grab the io_uring mutex.
> > >
> > > This is a preparatory patch that will be needed by fuse io-uring, which
> > > will need to select a buffer from a kernel-managed bufring while the
> > > uring mutex may already be held by in-progress commits, and may need to
> > > select a buffer in atomic contexts.
> > >
> > > Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
> > > ---
> > >  include/linux/io_uring/buf.h | 25 +++++++++++++++++++++++++
> > >  io_uring/kbuf.c              |  8 +++++---
> > >  2 files changed, 30 insertions(+), 3 deletions(-)
> > >  create mode 100644 include/linux/io_uring/buf.h
> > >
> > > diff --git a/include/linux/io_uring/buf.h b/include/linux/io_uring/buf.h
> > > new file mode 100644
> > > index 000000000000..3f7426ced3eb
> > > --- /dev/null
> > > +++ b/include/linux/io_uring/buf.h
> > > @@ -0,0 +1,25 @@
> > > +/* SPDX-License-Identifier: GPL-2.0-or-later */
> > > +#ifndef _LINUX_IO_URING_BUF_H
> > > +#define _LINUX_IO_URING_BUF_H
> > > +
> > > +#include <linux/io_uring_types.h>
> > > +
> > > +#if defined(CONFIG_IO_URING)
> > > +struct io_br_sel io_ring_buffer_select(struct io_kiocb *req, size_t *len,
> >
> > I think struct io_kiocb isn't intended to be exposed outside of
> > io_uring internal code. Is there a reason not to instead expose a
> > wrapper function that takes struct io_uring_cmd * instead?
>
> Oh interesting... I see struct io_kiocb defined in
> include/linux/io_uring_types.h, so I assumed this was fine to use.

Yeah, I see a lot of types that look io_uring-internal in
include/linux/io_uring_types.h. I'm not sure why they're visible to
the rest of the kernel rather than forward declared. But Jens please
correct me if I'm misunderstanding whether these types are meant to be
private to the io_uring subsystem.

> Hmm, we could wrap this in io_uring_cmd * instead, but that adds an
> extra layer and I think it clashes with the philosophy of io_uring_cmd
> being a "general user interface" (or maybe my interpretation of
> io_uring_cmd is incorrect) whereas this api is pretty io-uring

That's my understanding of io_uring_cmd too.

> internal specific (eg bypasses the io ring lock which means it'll be
> responsible for having to do its own synchronization, passing the
> io_buffer_list pointer directly, etc.).

That's a good point. I wonder if there's a better way to encapsulate
this for general usage outside of io_uring? I'm not that familiar with
io_uring buffer rings, though.

Best,
Caleb