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

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

[Xiang Gao]

From: gaoxiang17 <gaoxiang17@xiaomi.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.

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@xiaomi.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);
+	}
+
 	return dmabuf;
 
 err_dmabuf:
@@ -779,6 +792,11 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags)
 
 	fd_install(fd, dmabuf->file);
 
+	if (trace_dma_buf_fd_enabled()) {
+		guard(spinlock)(&dmabuf->name_lock);
+		trace_dma_buf_fd(dmabuf, fd);
+	}
+
 	return fd;
 }
 EXPORT_SYMBOL_NS_GPL(dma_buf_fd, "DMA_BUF");
@@ -794,6 +812,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_fd, "DMA_BUF");
 struct dma_buf *dma_buf_get(int fd)
 {
 	struct file *file;
+	struct dma_buf *dmabuf;
 
 	file = fget(fd);
 
@@ -805,7 +824,14 @@ struct dma_buf *dma_buf_get(int fd)
 		return ERR_PTR(-EINVAL);
 	}
 
-	return file->private_data;
+	dmabuf = file->private_data;
+
+	if (trace_dma_buf_get_enabled()) {
+		guard(spinlock)(&dmabuf->name_lock);
+		trace_dma_buf_get(dmabuf, fd);
+	}
+
+	return dmabuf;
 }
 EXPORT_SYMBOL_NS_GPL(dma_buf_get, "DMA_BUF");
 
@@ -825,6 +851,11 @@ void dma_buf_put(struct dma_buf *dmabuf)
 		return;
 
 	fput(dmabuf->file);
+
+	if (trace_dma_buf_put_enabled()) {
+		guard(spinlock)(&dmabuf->name_lock);
+		trace_dma_buf_put(dmabuf);
+	}
 }
 EXPORT_SYMBOL_NS_GPL(dma_buf_put, "DMA_BUF");
 
@@ -979,6 +1010,11 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
 	list_add(&attach->node, &dmabuf->attachments);
 	dma_resv_unlock(dmabuf->resv);
 
+	if (trace_dma_buf_dynamic_attach_enabled()) {
+		guard(spinlock)(&dmabuf->name_lock);
+		trace_dma_buf_dynamic_attach(dmabuf, dma_buf_attachment_is_dynamic(attach), dev);
+	}
+
 	return attach;
 
 err_attach:
@@ -1023,6 +1059,11 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
 	if (dmabuf->ops->detach)
 		dmabuf->ops->detach(dmabuf, attach);
 
+	if (trace_dma_buf_detach_enabled()) {
+		guard(spinlock)(&dmabuf->name_lock);
+		trace_dma_buf_detach(dmabuf, dma_buf_attachment_is_dynamic(attach), attach->dev);
+	}
+
 	kfree(attach);
 }
 EXPORT_SYMBOL_NS_GPL(dma_buf_detach, "DMA_BUF");
@@ -1488,6 +1529,11 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
 	vma_set_file(vma, dmabuf->file);
 	vma->vm_pgoff = pgoff;
 
+	if (trace_dma_buf_mmap_enabled()) {
+		guard(spinlock)(&dmabuf->name_lock);
+		trace_dma_buf_mmap(dmabuf);
+	}
+
 	return dmabuf->ops->mmap(dmabuf, vma);
 }
 EXPORT_SYMBOL_NS_GPL(dma_buf_mmap, "DMA_BUF");
diff --git a/include/trace/events/dma_buf.h b/include/trace/events/dma_buf.h
new file mode 100644
index 000000000000..f4b6ba5241fa
--- /dev/null
+++ b/include/trace/events/dma_buf.h
@@ -0,0 +1,160 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM dma_buf
+
+#if !defined(_TRACE_DMA_BUF_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_DMA_BUF_H
+
+#include <linux/dma-buf.h>
+#include <linux/tracepoint.h>
+
+DECLARE_EVENT_CLASS(dma_buf,
+
+	TP_PROTO(struct dma_buf *dmabuf),
+
+	TP_ARGS(dmabuf),
+
+	TP_STRUCT__entry(
+		__string(exp_name, dmabuf->exp_name)
+		__string(name, dmabuf->name)
+		__field(size_t, size)
+		__field(ino_t, ino)
+	),
+
+	TP_fast_assign(
+		__assign_str(exp_name);
+		__assign_str(name);
+		__entry->size = dmabuf->size;
+		__entry->ino = dmabuf->file->f_inode->i_ino;
+	),
+
+	TP_printk("exp_name=%s name=%s size=%zu ino=%lu",
+		  __get_str(exp_name),
+		  __get_str(name),
+		  __entry->size,
+		  __entry->ino)
+);
+
+DECLARE_EVENT_CLASS(dma_buf_attach_dev,
+
+	TP_PROTO(struct dma_buf *dmabuf, bool is_dynamic, struct device *dev),
+
+	TP_ARGS(dmabuf, is_dynamic, dev),
+
+	TP_STRUCT__entry(
+		__string(dev_name, dev_name(dev))
+		__string(exp_name, dmabuf->exp_name)
+		__string(name, dmabuf->name)
+		__field(size_t, size)
+		__field(ino_t, ino)
+		__field(bool, is_dynamic)
+	),
+
+	TP_fast_assign(
+		__assign_str(dev_name);
+		__assign_str(exp_name);
+		__assign_str(name);
+		__entry->size = dmabuf->size;
+		__entry->ino = dmabuf->file->f_inode->i_ino;
+		__entry->is_dynamic = is_dynamic;
+	),
+
+	TP_printk("exp_name=%s name=%s size=%zu ino=%lu is_dynamic=%d dev_name=%s",
+		  __get_str(exp_name),
+		  __get_str(name),
+		  __entry->size,
+		  __entry->ino,
+		  __entry->is_dynamic,
+		  __get_str(dev_name))
+);
+
+DECLARE_EVENT_CLASS(dma_buf_fd,
+
+	TP_PROTO(struct dma_buf *dmabuf, int fd),
+
+	TP_ARGS(dmabuf, fd),
+
+	TP_STRUCT__entry(
+		__string(exp_name, dmabuf->exp_name)
+		__string(name, dmabuf->name)
+		__field(size_t, size)
+		__field(ino_t, ino)
+		__field(int, fd)
+	),
+
+	TP_fast_assign(
+		__assign_str(exp_name);
+		__assign_str(name);
+		__entry->size = dmabuf->size;
+		__entry->ino = dmabuf->file->f_inode->i_ino;
+		__entry->fd = fd;
+	),
+
+	TP_printk("exp_name=%s name=%s size=%zu ino=%lu fd=%d",
+		  __get_str(exp_name),
+		  __get_str(name),
+		  __entry->size,
+		  __entry->ino,
+		  __entry->fd)
+);
+
+DEFINE_EVENT(dma_buf, dma_buf_export,
+
+	TP_PROTO(struct dma_buf *dmabuf),
+
+	TP_ARGS(dmabuf)
+);
+
+DEFINE_EVENT(dma_buf, dma_buf_mmap_internal,
+
+	TP_PROTO(struct dma_buf *dmabuf),
+
+	TP_ARGS(dmabuf)
+);
+
+DEFINE_EVENT(dma_buf, dma_buf_mmap,
+
+	TP_PROTO(struct dma_buf *dmabuf),
+
+	TP_ARGS(dmabuf)
+);
+
+DEFINE_EVENT(dma_buf, dma_buf_put,
+
+	TP_PROTO(struct dma_buf *dmabuf),
+
+	TP_ARGS(dmabuf)
+);
+
+DEFINE_EVENT(dma_buf_attach_dev, dma_buf_dynamic_attach,
+
+	TP_PROTO(struct dma_buf *dmabuf, bool is_dynamic, struct device *dev),
+
+	TP_ARGS(dmabuf, is_dynamic, dev)
+);
+
+DEFINE_EVENT(dma_buf_attach_dev, dma_buf_detach,
+
+	TP_PROTO(struct dma_buf *dmabuf, bool is_dynamic, struct device *dev),
+
+	TP_ARGS(dmabuf, is_dynamic, dev)
+);
+
+DEFINE_EVENT(dma_buf_fd, dma_buf_fd,
+
+	TP_PROTO(struct dma_buf *dmabuf, int fd),
+
+	TP_ARGS(dmabuf, fd)
+);
+
+DEFINE_EVENT(dma_buf_fd, dma_buf_get,
+
+	TP_PROTO(struct dma_buf *dmabuf, int fd),
+
+	TP_ARGS(dmabuf, fd)
+);
+
+#endif /* _TRACE_DMA_BUF_H */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
-- 
2.34.1

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

[Barry Song]

On Fri, Nov 28, 2025 at 4:53 PM Xiang Gao <gxxa03070307@gmail.com> wrote:
>
> From: gaoxiang17 <gaoxiang17@xiaomi.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@xiaomi.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);

?

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

[Christian König]

On 11/28/25 10:31, Barry Song wrote:
> On Fri, Nov 28, 2025 at 4:53 PM Xiang Gao <gxxa03070307@gmail.com> wrote:
>>
>> From: gaoxiang17 <gaoxiang17@xiaomi.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@xiaomi.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.

Re: 答复: [External Mail]Re: [PATCH v4] dma-buf: add some tracepoints to debug.

[Christian König]

On 12/1/25 02:44, 高翔 wrote:
>> 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.
> At present, from the perspective of processes, trace still makes sense.

Yeah, it probably do in most use cases. I just want to cover all use cases.

Maybe just use %p to print the attachment pointer until we have something better.

> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *发件人:* 高翔
> *发送时间:* 2025年11月28日 21:14:14
> *收件人:* Christian König; Barry Song; Xiang Gao
> *抄送:* sumit.semwal@linaro.org; rostedt@goodmis.org; mhiramat@kernel.org; linux-media@vger.kernel.org; dri-devel@lists.freedesktop.org; linux-kernel@vger.kernel.org; mathieu.desnoyers@efficios.com; dhowells@redhat.com; kuba@kernel.org; brauner@kernel.org; akpm@linux-foundation.org; linux-trace-kernel@vger.kernel.org
> *主题:* 答复: [External Mail]Re: [PATCH v4] dma-buf: add some tracepoints to debug.
>  
> 
>> 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.
> 
> Many threads use dmabuf "qcom,system". If there is a userspace name, we can immediately find the dmabuf I'm using. It might indeed not be necessary in other scenarios.

The DMA-buf "name" is an userspace assigned name and *not* useable for what you suggest here.

E.g. it is usually something like "texture", "shader", "dummy", "global"....

Could be that you have a driver or use case where it is something more specific and we can keep it where it makes sense for you, but I strongly suggest to always print the ino first since that one is guaranteed to be unique.

Regards,
Christian.

> 
> 
>> 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.
> 
> This requires some thought.
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *发件人:* Christian König <christian.koenig@amd.com>
> *发送时间:* 2025年11月28日 17:39:31
> *收件人:* Barry Song; Xiang Gao
> *抄送:* sumit.semwal@linaro.org; rostedt@goodmis.org; mhiramat@kernel.org; linux-media@vger.kernel.org; dri-devel@lists.freedesktop.org; linux-kernel@vger.kernel.org; mathieu.desnoyers@efficios.com; dhowells@redhat.com; kuba@kernel.org; brauner@kernel.org; akpm@linux-foundation.org; linux-trace-kernel@vger.kernel.org; 高翔
> *主题:* [External Mail]Re: [PATCH v4] dma-buf: add some tracepoints to debug.
>  
> [外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给misec@xiaomi.com进行反馈
> 
> On 11/28/25 10:31, Barry Song wrote:
>> On Fri, Nov 28, 2025 at 4:53 PM Xiang Gao <gxxa03070307@gmail.com> wrote:
>>>
>>> From: gaoxiang17 <gaoxiang17@xiaomi.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@xiaomi.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.
>