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

[Bernd Schubert <bernd@bsbernd.com>]

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.


Thanks,
Bernd