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

[Julian Orth]

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

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