Re: Regression due to /sys/kernel/dmabuf/buffers removal

[T.J. Mercier]

On Thu, May 7, 2026 at 4:35 AM Christian König <christian.koenig@xxxxxxx> wrote:
>
> On 5/5/26 16:32, T.J. Mercier wrote:
> > On Tue, May 5, 2026 at 6:00 AM Julian Orth <ju.orth@xxxxxxxxx> wrote:
> >>
> >> On Tue, May 5, 2026 at 2:41 PM Christian König <christian.koenig@xxxxxxx> 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
> >>>
>