linux-kernel - Re: [PATCH 2/4] bpf: Add dmabuf iterator

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPhsuW54g5YCmLVX=cc3m2nfQTZrMH+6ZMBgouEMMfqcccOtww@mail.gmail.com>
Date: Mon, 21 Apr 2025 10:58:33 -0700
From: Song Liu <song@...nel.org>
To: "T.J. Mercier" <tjmercier@...gle.com>
Cc: sumit.semwal@...aro.org, christian.koenig@....com, ast@...nel.org, 
	daniel@...earbox.net, andrii@...nel.org, martin.lau@...ux.dev, 
	skhan@...uxfoundation.org, linux-kernel@...r.kernel.org, 
	linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org, 
	linaro-mm-sig@...ts.linaro.org, linux-doc@...r.kernel.org, 
	bpf@...r.kernel.org, linux-kselftest@...r.kernel.org, android-mm@...gle.com, 
	simona@...ll.ch, corbet@....net, eddyz87@...il.com, yonghong.song@...ux.dev, 
	john.fastabend@...il.com, kpsingh@...nel.org, sdf@...ichev.me, 
	jolsa@...nel.org, mykolal@...com
Subject: Re: [PATCH 2/4] bpf: Add dmabuf iterator

On Mon, Apr 14, 2025 at 3:53 PM T.J. Mercier <tjmercier@...gle.com> wrote:
>
> The dmabuf iterator traverses the list of all DMA buffers. The list is
> maintained only when CONFIG_DEBUG_FS is enabled.
>
> DMA buffers are refcounted through their associated struct file. A
> reference is taken on each buffer as the list is iterated to ensure each
> buffer persists for the duration of the bpf program execution without
> holding the list mutex.
>
> Signed-off-by: T.J. Mercier <tjmercier@...gle.com>
> ---
>  include/linux/btf_ids.h  |   1 +
>  kernel/bpf/Makefile      |   3 +
>  kernel/bpf/dmabuf_iter.c | 130 +++++++++++++++++++++++++++++++++++++++
>  3 files changed, 134 insertions(+)
>  create mode 100644 kernel/bpf/dmabuf_iter.c
>
> diff --git a/include/linux/btf_ids.h b/include/linux/btf_ids.h
> index 139bdececdcf..899ead57d89d 100644
> --- a/include/linux/btf_ids.h
> +++ b/include/linux/btf_ids.h
> @@ -284,5 +284,6 @@ extern u32 bpf_cgroup_btf_id[];
>  extern u32 bpf_local_storage_map_btf_id[];
>  extern u32 btf_bpf_map_id[];
>  extern u32 bpf_kmem_cache_btf_id[];
> +extern u32 bpf_dmabuf_btf_id[];

This is not necessary. See below.

>
>  #endif
> diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile
> index 70502f038b92..5b30d37ef055 100644
> --- a/kernel/bpf/Makefile
> +++ b/kernel/bpf/Makefile
> @@ -53,6 +53,9 @@ obj-$(CONFIG_BPF_SYSCALL) += relo_core.o
>  obj-$(CONFIG_BPF_SYSCALL) += btf_iter.o
>  obj-$(CONFIG_BPF_SYSCALL) += btf_relocate.o
>  obj-$(CONFIG_BPF_SYSCALL) += kmem_cache_iter.o
> +ifeq ($(CONFIG_DEBUG_FS),y)
> +obj-$(CONFIG_BPF_SYSCALL) += dmabuf_iter.o
> +endif
>
>  CFLAGS_REMOVE_percpu_freelist.o = $(CC_FLAGS_FTRACE)
>  CFLAGS_REMOVE_bpf_lru_list.o = $(CC_FLAGS_FTRACE)
> diff --git a/kernel/bpf/dmabuf_iter.c b/kernel/bpf/dmabuf_iter.c
> 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.

> @@ -0,0 +1,130 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/* Copyright (c) 2025 Google LLC */
> +#include <linux/bpf.h>
> +#include <linux/btf_ids.h>
> +#include <linux/dma-buf.h>
> +#include <linux/kernel.h>
> +#include <linux/seq_file.h>
> +
> +BTF_ID_LIST_GLOBAL_SINGLE(bpf_dmabuf_btf_id, struct, dma_buf)

Use BTF_ID_LIST_SINGLE(), then we don't need this in btf_ids.h

> +DEFINE_BPF_ITER_FUNC(dmabuf, struct bpf_iter_meta *meta, struct dma_buf *dmabuf)
> +
> +static void *dmabuf_iter_seq_start(struct seq_file *seq, loff_t *pos)
> +{
> +       struct dma_buf *dmabuf, *ret = NULL;
> +
> +       if (*pos) {
> +               *pos = 0;
> +               return NULL;
> +       }
> +       /* Look for the first buffer we can obtain a reference to.
> +        * The list mutex does not protect a dmabuf's refcount, so it can be
> +        * zeroed while we are iterating. Therefore we cannot call get_dma_buf()
> +        * since the caller of this program may not already own a reference to
> +        * the buffer.
> +        */

We should use kernel comment style for new code. IOW,
/*
 * Look for ...
 */


Thanks,
Song

[...]