On Thu, May 7, 2026 at 4:35 AM Christian König <[email protected]> wrote: > > 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.
Ah, this? https://source.android.com/docs/core/graphics/implement-dma-buf-gpu-mem I will update it to mark it as deprecated, and only applicable to kernels < 6.18 where CONFIG_DMABUF_SYSFS_STATS was first disabled. source.android.com updates are usually released with the platform, which is very soon for Android 17. > > 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 > >>> >
