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:18, Christoph Hellwig wrote:
> On Thu, Feb 12, 2026 at 10:44:44AM +0000, Pavel Begunkov wrote:
>>>
>>> Any pages mapped to userspace can be allocated in the kernel as well.
>>
>> pow2 round ups will waste memory. 1MB allocations will never
>> become 2MB huge pages. And there is a separate question of
>> 1GB huge pages. The user can be smarter about all placement
>> decisions.
> 
> Sure.  But if the application cares that much about TLB pressure
> I'd just round up to nice multtiple of PTE levels.
> 
>>
>>> And I really do like this design, because it means we can have a
>>> buffer ring that is only mapped read-only into userspace.  That way
>>> we can still do zero-copy raids if the device requires stable pages
>>> for checksumming or raid.  I was going to implement this as soon
>>> as this series lands upstream.
>>
>> That's an interesting case. To be clear, user provided memory is
>> an optional feature for pbuf rings / regions / etc., and I think
>> the io_uring uapi should leave fields for the feature. However, I
>> have nothing against fuse refusing to bind to buffer rings it
>> doesn't like.
> 
> Can you clarify what you mean with 'pbuf'?  The only fixed buffer API I
> know is io_uring_register_buffers* which always takes user provided
> buffers, so I have a hard time parsing what you're saying there.  But
> that might just be sign that I'm no expert in io_uring APIs, and that
> web searches have degraded to the point of not being very useful
> anymore.

Registered, aka fixed, buffers are the ones you pass to
IORING_OP_[READ,WRITE]_FIXED and some other requests. It's normally
created by io_uring_register_buffers*() / IORING_REGISTER_BUFFERS*
with user memory, but there are special cases when it's installed
internally by other kernel components, e.g. ublk.
This series has nothing to do with them, and relevant parts of
the discussion here don't mention them either.

Provided buffer rings, a.k.a pbuf rings, IORING_REGISTER_PBUF_RING
is a kernel-user shared ring. The entries are user buffers
{uaddr, size}. The user space adds entries, the kernel (io_uring
requests) consumes them and issues I/O using the user addresses.
E.g. you can issue a IORING_OP_RECV request (+IOSQE_BUFFER_SELECT)
and it'll grab a buffer from the ring instead of using sqe->addr.

pbuf rings, IORING_REGISTER_MEM_REGION, completion/submission
queues and all other kernel-user rings/etc. are internally based
on so called regions. All of them support both user allocated
memory and kernel allocations + mmap.

This series essentially creates provided buffer rings, where
1. the ring now contains kernel addresses
2. the ring itself is in-kernel only and not shared with user space
3. it also allocates kernel buffers (as a region), populates the ring
    with them, and allows mapping the buffers into the user space.

Fuse is doing both adding (kernel) buffers to the ring and consuming
them. At which point it's not clear:

1. Why it even needs io_uring provided buffer rings, it can be all
    contained in fuse. Maybe it's trying to reuse pbuf ring code as
    basically an internal memory allocator, but then why expose buffer
    rings as an io_uring uapi instead of keeping it internally.

    That's also why I mentioned whether those buffers are supposed to
    be used with other types of io_uring requests like recv, etc.

2. Why making io_uring to allocate payload memory. The answer to which
    is probably to reuse the region api with mmap and so on. And why
    payload buffers are inseparably created together with the ring
    and via a new io_uring uapi.

    And yes, I believe in the current form it's inflexible, it requires
    a new io_uring uapi. It requires the number of buffers to match
    the number of ring entries, which are related but not the same
    thing. You can't easily add more memory as it's bound to the ring
    object. The buffer memory won't even have same lifetime as the
    ring object -- allow using that km buffer ring with recv requests
    and highly likely I'll most likely give you a way to crash the
    kernel.

But hey, I'm tired. I don't have any beef here and am only trying
to make it a bit cleaner and flexible for fuse in the first place
without even questioning the I/O path. If everyone believes
everything is right, just ask Jens to merge it.

-- 
Pavel Begunkov