On Thu, Apr 17, 2025 at 1:26 PM Song Liu song@kernel.org wrote:

On Thu, Apr 17, 2025 at 9:05 AM T.J. Mercier tjmercier@google.com wrote:

...

On Wed, Apr 16, 2025 at 9:56 PM Song Liu song@kernel.org wrote:

...

On Wed, Apr 16, 2025 at 7:09 PM T.J. Mercier tjmercier@google.com wrote:

...

On Wed, Apr 16, 2025 at 6:26 PM Song Liu song@kernel.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.

...

...

OTOH, I am wondering whether we can build a more generic iterator for a list of objects. Adding a iterator for each important kernel lists seems not scalable in the long term.

I think the wide variety of differences in locking for different objects would make this difficult to do in a generic way.

Agreed it is not easy to build a generic solution. But with the help from BTF, we can probably build something that covers a large number of use cases.

I'm curious what this would look like. I guess a good test would be to see if anything would work for some subset of the already existing iterators.