Re: [PATCH V2 08/13] io_uring: bpf: add uring_bpf_memcpy() kfunc

[Ming Lei <ming.lei@redhat.com>]

On Fri, Mar 13, 2026 at 10:18:53PM -0700, Caleb Sander Mateos wrote:
> On Tue, Jan 6, 2026 at 2:12 AM Ming Lei <ming.lei@redhat.com> wrote:
> >
> > Add uring_bpf_memcpy() kfunc that copies data between io_uring BPF
> > buffers. This kfunc supports all 5 buffer types defined in
> > io_bpf_buf_desc:
> >
> > - IO_BPF_BUF_USER: plain userspace buffer
> > - IO_BPF_BUF_FIXED: fixed buffer (absolute address within buffer)
> > - IO_BPF_BUF_VEC: vectored userspace buffer (iovec array)
> > - IO_BPF_BUF_KFIXED: kernel fixed buffer (offset-based addressing)
> > - IO_BPF_BUF_KVEC: kernel vectored buffer
> >
> > Add helper functions for buffer import:
> > - io_bpf_import_fixed_buf(): handles FIXED/KFIXED types with proper
> >   node reference counting
> > - io_bpf_import_kvec_buf(): handles KVEC using __io_prep_reg_iovec()
> >   and __io_import_reg_vec()
> > - io_bpf_import_buffer(): unified dispatcher for all buffer types
> > - io_bpf_copy_iters(): page-based copy between iov_iters
> >
> > The kfunc properly manages buffer node references and submit lock
> > for registered buffer access.
> 
> Ming,
> 
> Thank you for working on this patch series and sorry I didn't have a
> chance to take a look at this revision earlier.
> 
> My main reservation with this approach is that a dedicated kfunc is
> needed for each data manipulation operation an io_uring BPF program
> conceivably wants to perform. Even for the initial RAID parity
> calculation use case, I imagine we'd need a different kfunc for each
> RAID stripe data width and parity width combination. Other data
> operations added in the future would also need new kfuncs to support
> them.
> struct io_bpf_buf_desc is certainly more flexible than the approach in
> v1, but I worry that fully consuming the iterator in a single kfunc
> call prevents composing data operations during a single pass over the
> buffer. For example, if the input data needs to be encrypted and then
> parity needs to be generated over the encrypted data, calling an
> encryption kfunc and a parity generation kfunc in sequence would
> perform two passes over the data. To do it in a single pass, you'd
> need something like an "encrypt_and_gen_parity()" kfunc, which seems
> very niche.

parity buffer should be owned by ublk server.

So here you want to calculate parity over encrypted registered buffer
in one pass.

Technically it should be doable, however it depends if the in-kernel
encryption lib supports it, or it may be too slow.

> The hope was that io_uring BPF programs would provide a generic
> approach to registered buffer data manipulation, but the dependency on
> a large set of kfuncs seems a significant hurdle. I suspect a fully
> generic approach would require essentially reproducing the struct
> iov_iter abstraction in kfunc form.

bpf iterator might be the solution, but looks one limit is that it is hard
or not possible to produce one writeable buffer from bpf_iter_next() kfunc,
so one encrypt kfunc is still needed. If the encrypt lib supports to generate
parity data in one pass, the kfunc may support it, however, I feel it might
be hard.

Also I guess one extra pass for calculating parity shouldn't be too bad,
and here one extra decrypt kfunc is enough, and calculating & storing parity
can be done directly because the parity buffer is not registered.


Thanks,
Ming