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

[Pavel Begunkov <asml.silence@gmail.com>]

On 2/13/26 07:21, Christoph Hellwig wrote:
> On Thu, Feb 12, 2026 at 10:52:29AM +0000, Pavel Begunkov 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
>>> to be able to piggy back than onto your work.
>>
>> IORING_REGISTER_MEM_REGION supports both types of allocations. It can
>> have a new registration flag for read-only, and then you either make
> 
> IORING_REGISTER_MEM_REGION seems to be all about cqs from both your
> commit message and the public documentation.  I'm confused.

Think of it as an area of memory for kernel-user communication. Used
for syscall parameters passing to avoid copy_from_user, but I added
it for a bunch of use cases. We'll hopefully get support at some
point for passing request arguments like struct iovec. BPF patches
use it for communication. I need to respin patches placing SQ/CQ onto
it (avoid some memory waste).

Tbh, I never meant it nor io_uring regions to be used for huge
payload buffers, but this series already uses regions for that.


>> the bounce avoidance optional or reject binding fuse to unsupported
>> setups during init. Any arguments against that? I need to go over
>> Joanne's reply, but I don't see any contradiction in principal with
>> your use case.
> 
> My use case is not about fuse, but good old block and file system
> I/O.

Then I'm confused. Take a look at the other reply, this series is
about buffer rings with kernel memory, it can't work without a kernel
component returning buffers into the ring, and io_uring doesn't do
that. But maybe you're thinking about adding some more elaborate API.

IIUC, Joanne also wants to add support for fuse installing registered
buffers, which would allow zero-copy, but those got split out of
this series.

-- 
Pavel Begunkov