Re: [PATCH v1 03/11] io_uring/kbuf: add support for kernel-managed buffer rings

[Joanne Koong <joannelkoong@gmail.com>]

On Fri, Feb 13, 2026 at 11:30 AM Bernd Schubert <bernd@bsbernd.com> wrote:
>
>
>
> On 2/13/26 20:09, Joanne Koong wrote:
> > On Fri, Feb 13, 2026 at 7:31 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
> >>
> >> On 2/13/26 07:27, Christoph Hellwig wrote:
> >>> On Thu, Feb 12, 2026 at 09:29:31AM -0800, Joanne Koong wrote:
> >>>>>> I'm arguing exactly against this.  For my use case I need a setup
> >>>>>> where the kernel controls the allocation fully and guarantees user
> >>>>>> processes can only read the memory but never write to it.  I'd love
> >>>>
> >>>> By "control the allocation fully" do you mean for your use case, the
> >>>> allocation/setup isn't triggered by userspace but is initiated by the
> >>>> kernel (eg user never explicitly registers any kbuf ring, the kernel
> >>>> just uses the kbuf ring data structure internally and users can read
> >>>> the buffer contents)? If userspace initiates the setup of the kbuf
> >>>> ring, going through IORING_REGISTER_MEM_REGION would be semantically
> >>>> the same, except the buffer allocation by the kernel now happens
> >>>> before the ring is created and then later populated into the ring.
> >>>> userspace would still need to make an mmap call to the region and the
> >>>> kernel could enforce that as read-only. But if userspace doesn't
> >>>> initiate the setup, then going through IORING_REGISTER_MEM_REGION gets
> >>>> uglier.
> >>>
> >>> The idea is that the application tells the kernel that it wants to use
> >>> a fixed buffer pool for reads.  Right now the application does this
> >>> using io_uring_register_buffers().  The problem with that is that
> >>> io_uring_register_buffers ends up just doing a pin of the memory,
> >>> but the application or, in case of shared memory, someone else could
> >>> still modify the memory.  If the underlying file system or storage
> >>> device needs verify checksums, or worse rebuild data from parity
> >>> (or uncompress), it needs to ensure that the memory it is operating
> >>> on can't be modified by someone else.
> >>>
> >>> So I've been thinking of a version of io_uring_register_buffers where
> >>> the buffers are not provided by the application, but instead by the
> >>> kernel and mapped into the application address space read-only for
> >>> a while, and I thought I could implement this on top of your series,
> >>> but I have to admit I haven't really looked into the details all
> >>> that much.
> >>
> >> There is nothing about registered buffers in this series. And even
> >> if you try to reuse buffer allocation out of it, it'll come with
> >> a circular buffer you'll have no need for. And I'm pretty much
> >
> > I think the circular buffer will be useful for Christoph's use case in
> > the same way it'll be useful for fuse's. The read payload could be
> > differently sized across requests, so it's a lot of wasted space to
> > have to allocate a buffer large enough to support the max-size request
> > per entry in the io_ring. With using a circular buffer, buffers have a
> > way to be shared across entries, which means we can significantly
> > reduce how much memory needs to be allocated.
>
> Dunno, what we actually want is requests of multiple sizes. Sharing
> buffers across entries sounds like just reducing the ring size - I
> personally don't see the point here.

By "sharing buffers across entries" what I mean is different regions
of the buffer can now be used concurrently by multiple entries.

Thanks,
Joanne
>
>
> Thanks,
> Bernd