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

["Christian König" <christian.koenig@amd.com>]

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