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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAPhsuW7G+Y3DcpN+N7c4wUuSGoq-DaUmLTAy87xAKWK=ZAZ+Dg@mail.gmail.com>
Date: Mon, 21 Apr 2025 11:12:56 -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 Fri, Apr 18, 2025 at 8:25 AM T.J. Mercier <tjmercier@...gle.com> wrote:
>
> On Thu, Apr 17, 2025 at 1:26 PM Song Liu <song@...nel.org> wrote:
> >
> > On Thu, Apr 17, 2025 at 9:05 AM T.J. Mercier <tjmercier@...gle.com> wrote:
> > >
> > > On Wed, Apr 16, 2025 at 9:56 PM Song Liu <song@...nel.org> wrote:
> > > >
> > > > On Wed, Apr 16, 2025 at 7:09 PM T.J. Mercier <tjmercier@...gle.com> wrote:
> > > > >
> > > > > On Wed, Apr 16, 2025 at 6:26 PM Song Liu <song@...nel.org> wrote:
> > > > [...]
> > > > > >
> > > > > > Here is another rookie question, it appears to me there is a file descriptor
> > > > > > associated with each DMA buffer, can we achieve the same goal with
> > > > > > a task-file iterator?
> > > > >
> > > > > That would find almost all of them, but not the kernel-only
> > > > > allocations. (kernel_rss in the dmabuf_dump output I attached earlier.
> > > > > If there's a leak, it's likely to show up in kernel_rss because some
> > > > > driver forgot to release its reference(s).) Also wouldn't that be a
> > > > > ton more iterations since we'd have to visit every FD to find the
> > > > > small portion that are dmabufs? I'm not actually sure if buffers that
> > > > > have been mapped, and then have had their file descriptors closed
> > > > > would show up in task_struct->files; if not I think that would mean
> > > > > scanning both files and vmas for each task.
> > > >
> > > > I don't think scanning all FDs to find a small portion of specific FDs
> > > > is a real issue. We have a tool that scans all FDs in the system and
> > > > only dump data for perf_event FDs. I think it should be easy to
> > > > prototype a tool by scanning all files and all vmas. If that turns out
> > > > to be very slow, which I highly doubt will be, we can try other
> > > > approaches.
> > >
> > > But this will not find *all* the buffers, and that defeats the purpose
> > > of having the iterator.
> >
> > Do you mean this approach cannot get kernel only allocations? If
> > that's the case, we probably do need a separate iterator. I am
> > interested in other folks thoughts on this.
>
> Correct.

I read more into the code, and realized that udmabuf fd is not for
the same file here. I guess this also justifies a separate iterator.

Thanks,
Song