On 5/5/26 16:32, T.J. Mercier wrote: > On Tue, May 5, 2026 at 6:00 AM Julian Orth <[email protected]> wrote: >> >> On Tue, May 5, 2026 at 2:41 PM Christian König <[email protected]> >> 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.
Yeah, exactly my thinking as well :) A college questioned me this week how to find DMA-buf stats for debugging and it turned out that Google points to the outdated DMA-buf sysfs documentation instead of the debugfs one. No idea why, maybe we need to improve the documentation here a bit. > Adding an ioctl would introduce new UAPI so I think we'd want to avoid > that unless absolutely necessary. CRIU has some similar requirements, e.g. they need to know the exporting driver of a DMA-buf. Not sure if the fdinfo file will be sufficient for that case or not. But yeah I agree that we only need this if actually necessary. Regards, Christian. > > 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 >>>
