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. 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 > >
