On Tue, May 5, 2026 at 6:00 AM Julian Orth ju.orth@gmail.com wrote:
On Tue, May 5, 2026 at 2:41 PM Christian König christian.koenig@amd.com wrote:
Hi Julian,
On 5/5/26 14:25, Julian Orth wrote:
In ab4c3dcf9a71582503b4fb25aeab884c696cab25 ("dma-buf: Remove DMA-BUF sysfs stats") the /sys/kernel/dmabuf/buffer directory was removed.
I've been using this interface, specifically the exporter_name file, to detect dmabufs created via udmabuf. Such dmabufs show "udmabuf" in exporter_name. I've been doing this for two reasons: 1) to detect that mmap on such buffers will be fast and 2) to detect that GPU access to such buffers will be slow.
Crap, I really hoped that Android was the only user of that sysfs interface since that approach turned out to be quite broken.
It's number one rule on Linux that we don't break userspace. So I hope that you don't insist on bringing that interface back, but if you do I will just revert the removal until we found a better solution.
Bringing it back shouldn't be necessary.
With the removal of that file, that detection mechanism no longer works.
I'm not particularly fond of that mechanism but it was the only one providing that functionality that I could find at the time. If there is another one, ideally an ioctl on the dmabuf, please let me know.
The virtual fdinfo file you can find under /proc/$pid/fdinfo/$fd also contains the exporter name for the DMA-buf.
You can find the full documentation here: https://docs.kernel.org/filesystems/proc.html#dma-buffer-files
Is that sufficient?
I think that is sufficient. I probably didn't use fdinfo initially because 1) it's a lot more work to parse and 2) I wasn't sure if it was intended to be machine-readable or if there could sometimes be newlines in the values and such.
Additional to that the debugfs for DMA-buf also contains that information and I'm open to the suggestion with the IOCTL.
My application runs as a regular user so it cannot access /sys/kernel/debug.
Having an IOCTL would be ideal if it is not too much work. I'll fall back to fdinfo for now.
Thanks, Julian
Phew, I'm glad fdinfo suits your needs.
Adding an ioctl would introduce new UAPI so I think we'd want to avoid that unless absolutely necessary.
Thanks, T.J.
Regards, Christian.
Shipping an entire BPF compiler in my application, which the original patch suggests as the replacement, is not an option when the removed alternative was simply reading a file.
Thanks, Julian