On Mon, Apr 21, 2025 at 4:39 PM Alexei Starovoitov alexei.starovoitov@gmail.com wrote:

On Mon, Apr 21, 2025 at 1:40 PM T.J. Mercier tjmercier@google.com wrote:

...

...

...

new file mode 100644 index 000000000000..b4b8be1d6aa4 --- /dev/null +++ b/kernel/bpf/dmabuf_iter.c

Maybe we should add this file to drivers/dma-buf. I would like to hear other folks thoughts on this.

This is fine with me, and would save us the extra CONFIG_DMA_SHARED_BUFFER check that's currently needed in kernel/bpf/Makefile but would require checking CONFIG_BPF instead. Sumit / Christian any objections to moving the dmabuf bpf iterator implementation into drivers/dma-buf?

The driver directory would need to 'depends on BPF_SYSCALL'. Are you sure you want this? imo kernel/bpf/ is fine for this.

I don't have a strong preference so either way is fine with me. The main difference I see is maintainership.

You also probably want .feature = BPF_ITER_RESCHED in bpf_dmabuf_reg_info.

Thank you, this looks like a good idea.

Also have you considered open coded iterator for dmabufs? Would it help with the interface to user space?

I read through the open coded iterator patches, and it looks like they would be slightly more efficient by avoiding seq_file overhead. As far as the interface to userspace, for the purpose of replacing what's currently exposed by CONFIG_DMABUF_SYSFS_STATS I don't think there is a difference. However it looks like if I were to try to replace all of our userspace analysis of dmabufs with a single bpf program then an open coded iterator would make that much easier. I had not considered attempting that.

One problem I see with open coded iterators is that support is much more recent (2023 vs 2020). We support longterm stable kernels (back to 5.4 currently but probably 5.10 by the time this would be used), so it seems like it would be harder to backport the kernel support for an open-coded iterator that far since it only goes back as far as 6.6 now. Actually it doesn't look like it is possible while also maintaining the stable ABI we provide to device vendors. Which means we couldn't get rid of the dmabuf sysfs stats userspace dependency until 6.1 EOL in Dec. 2027. :\ So I'm in favor of a traditional bpf iterator here for now.