linux-kernel - Re: [PATCH v4] dma-buf: add some tracepoints to debug.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <faf6a25c-03a7-41d2-8dd2-ba74ee2e02a9@amd.com>
Date: Fri, 28 Nov 2025 10:39:31 +0100
From: Christian König <christian.koenig@....com>
To: Barry Song <21cnbao@...il.com>, Xiang Gao <gxxa03070307@...il.com>
Cc: sumit.semwal@...aro.org, rostedt@...dmis.org, mhiramat@...nel.org,
 linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, mathieu.desnoyers@...icios.com,
 dhowells@...hat.com, kuba@...nel.org, brauner@...nel.org,
 akpm@...ux-foundation.org, linux-trace-kernel@...r.kernel.org,
 gaoxiang17 <gaoxiang17@...omi.com>
Subject: Re: [PATCH v4] dma-buf: add some tracepoints to debug.

On 11/28/25 10:31, Barry Song wrote:
> On Fri, Nov 28, 2025 at 4:53 PM Xiang Gao <gxxa03070307@...il.com> wrote:
>>
>> From: gaoxiang17 <gaoxiang17@...omi.com>
>>
>> I want to track the status of dmabuf in real time in the production environment.
>> But now we can only check it by traversing the fd in the process or dmabuf_list.
> 
> might be:
> 
> Since we can only inspect dmabuf by iterating over process FDs or the
> dmabuf_list, we need to add our own tracepoints to track its status in
> real time in production.
> 
>>
>> For example:
>>    binder:3031_4-18348   [005] ...1.   545.568275: dma_buf_export: exp_name=qcom,system name=(null) size=217088 ino=2750
>>    binder:3031_4-18348   [005] ...1.   545.568284: dma_buf_fd: exp_name=qcom,system name=(null) size=217088 ino=2750 fd=8
>>    binder:3031_4-18348   [005] ...1.   545.568399: dma_buf_mmap_internal: exp_name=qcom,system name=qcom,system size=28672 ino=2751
>>      kworker/5:1-130     [005] ...1.   545.570193: dma_buf_put: exp_name=qcom,system name=ab size=28672 ino=2751
>>     RenderThread-18891   [005] ...1.   545.602994: dma_buf_get: exp_name=qcom,system name=ab size=217088 ino=2750 fd=1087
>>     RenderThread-9409    [000] .n.1.   545.745004: dma_buf_dynamic_attach: exp_name=qcom,system name=ab size=217088 ino=2750 is_dynamic=0 dev_name=kgsl-3d0
>>     RenderThread-9409    [005] ...1.   545.747802: dma_buf_detach: exp_name=qcom,system name=bq size=12771328 ino=2764 is_dynamic=0 dev_name=kgsl-3d0
>>
>> Signed-off-by: Xiang Gao <gaoxiang17@...omi.com>
>> ---
>>  drivers/dma-buf/dma-buf.c      |  48 +++++++++-
>>  include/trace/events/dma_buf.h | 160 +++++++++++++++++++++++++++++++++
>>  2 files changed, 207 insertions(+), 1 deletion(-)
>>  create mode 100644 include/trace/events/dma_buf.h
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index 2bcf9ceca997..6e04e12f149e 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -35,6 +35,9 @@
>>
>>  #include "dma-buf-sysfs-stats.h"
>>
>> +#define CREATE_TRACE_POINTS
>> +#include <trace/events/dma_buf.h>
>> +
>>  static inline int is_dma_buf_file(struct file *);
>>
>>  static DEFINE_MUTEX(dmabuf_list_mutex);
>> @@ -220,6 +223,11 @@ static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma)
>>             dmabuf->size >> PAGE_SHIFT)
>>                 return -EINVAL;
>>
>> +       if (trace_dma_buf_mmap_internal_enabled()) {
>> +               guard(spinlock)(&dmabuf->name_lock);
>> +               trace_dma_buf_mmap_internal(dmabuf);
>> +       }
>> +
>>         return dmabuf->ops->mmap(dmabuf, vma);
>>  }
>>
>> @@ -745,6 +753,11 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
>>
>>         __dma_buf_list_add(dmabuf);
>>
>> +       if (trace_dma_buf_export_enabled()) {
>> +               guard(spinlock)(&dmabuf->name_lock);
>> +               trace_dma_buf_export(dmabuf);
>> +       }
>> +
> 
> perhaps a macro similar to the one below
> 
> #define DMA_BUF_TRACE(FUNC, ...)                  \
>     do {                                          \
>         if (FUNC##_enabled()) {                   \
>             guard(spinlock)(&dmabuf->name_lock); \
>             FUNC(__VA_ARGS__);                    \
>         }                                         \
>     } while (0)
> 
> 
> This would help us avoid duplicating a lot of code.
> 
> could be:
> DMA_BUF_TRACE(trace_dma_buf_put, dmabuf);
> DMA_BUF_TRACE(trace_dma_buf_attach, dmabuf, dev);
> 
> ?

Thinking more about it I was wondering if we really need the userspace assigned name in the tracepoint in the first place.

The ino should be sufficient to uniquely identify each dma-buf, tracing the name should only be printed if it's changing or otherwise we spam the tracelog quite a bit with it.

BTW We don't have any identification for an attachment, so when multiple devices attach to the same DMA-buf the trace would be quite meaningless. We should probably fix that.

Regards,
Christian.