On Wed, Apr 16, 2025 at 3:02 PM Song Liu song@kernel.org wrote:
On Mon, Apr 14, 2025 at 3:53 PM T.J. Mercier tjmercier@google.com wrote: [...]
+BTF_ID_LIST_GLOBAL_SINGLE(bpf_dmabuf_btf_id, struct, dma_buf) +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.*/mutex_lock(&dmabuf_debugfs_list_mutex);list_for_each_entry(dmabuf, &dmabuf_debugfs_list, list_node) {if (file_ref_get(&dmabuf->file->f_ref)) {ret = dmabuf;break;}}mutex_unlock(&dmabuf_debugfs_list_mutex);IIUC, the iterator simply traverses elements in a linked list. I feel it is an overkill to implement a new BPF iterator for it.
Like other BPF iterators such as kmem_cache_iter or task_iter. Cgroup_iter iterates trees instead of lists. This is iterating over kernel objects just like the docs say, "A BPF iterator is a type of BPF program that allows users to iterate over specific types of kernel objects". More complicated iteration should not be a requirement here.
Maybe we simply use debugging tools like crash or drgn for this? The access with these tools will not be protected by the mutex. But from my personal experience, this is not a big issue for user space debugging tools.
drgn is *way* too slow, and even if it weren't the dependencies for running it aren't available. crash needs debug symbols which also aren't available on user builds. This is not just for manual debugging, it's for reporting memory use in production. Or anything else someone might care to extract like attachment info or refcounts.
Thanks, Song
return ret;+}