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

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

[Julian Orth]

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.

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.

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

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

[Christian König]

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.

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

Additional to that the debugfs for DMA-buf also contains that information and I'm open to the suggestion with the IOCTL.

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

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

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

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

[T.J. Mercier]

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.

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

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

[Christian König]

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

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@amd.com> wrote:
>
> 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.

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