Re: [PATCH v2 13/14] fuse: add zero-copy over io-uring

[Bernd Schubert <bernd@bsbernd.com>]

On 4/30/26 14:55, Jeff Layton wrote:
> On Thu, 2026-04-30 at 13:35 +0100, Joanne Koong wrote:
>> On Thu, Apr 30, 2026 at 12:42 PM Jeff Layton <jlayton@kernel.org> wrote:
>>>
>>> On Thu, 2026-04-02 at 09:28 -0700, Joanne Koong wrote:
>>>> Implement zero-copy data transfer for fuse over io-uring, eliminating
>>>> memory copies between userspace, the kernel, and the fuse server for
>>>> page-backed read/write operations.
>>>>
>>>> When the FUSE_URING_ZERO_COPY flag is set alongside FUSE_URING_BUFRING,
>>>> the kernel registers the client's underlying pages as a sparse buffer at
>>>> the entry's fixed id via io_buffer_register_bvec(). The fuse server can
>>>> then perform io_uring read/write operations directly on these pages.
>>>> Non-page-backed args (eg out headers) go through the payload buffer as
>>>> normal.
>>>>
>>>> This requires CAP_SYS_ADMIN and buffer rings with pinned headers and
>>>> buffers. Gating on pinned headers and buffers keeps the configuration
>>>> space small and avoids partially-optimized modes that are unlikely to be
>>>> useful in practice. Pages are unregistered when the request completes.
>>>>
>>>
>>> Can you elaborate a bit more on why CAP_SYS_ADMIN is needed here? It's
>>> not immediately obvious to me.
>>
>> Thank you for reviewing this series, Jeff!
>>
>> This is gated behind CAP_SYS_ADMIN because zero-copy allows the server
>> direct access to the client's underlying pages, rather than operating
>> on an intermediary buffer that the contents of client's pages were
>> copied into. A malicious unprivileged server could keep direct access
>> to the client's pages (eg even if the client tries to cancel a
>> read/write, if the request was already sent to userspace, the server
>> will still have access to the underlying pages). In the non-zero-copy
>> path this isn't possible because the server only operates on the copy
>> of the pages and not on the actual pages.
>>
> 
> Thanks for the explanation. I'd suggest adding that to the commit
> message (and maybe comments near the CAP_SYS_ADMIN checks) in case
> others aren't clear why this is gated on that.

Silly question, isn't it very splice like? Fuse-server doesn't get the
access to the buffer, actually, but only forwards via io-uring. Splice
is allowed without CAP_SYS_ADMIN, so why does this need to have it?


Thanks,
Bernd