| 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
| ||
|
Message-ID: <7a7f8fec-f0cb-4dfc-9a3e-216050515ad3@amd.com>
Date: Mon, 1 Dec 2025 09:24:01 +0100
From: Christian König <christian.koenig@....com>
To: 高翔 <gaoxiang17@...omi.com>,
Barry Song <21cnbao@...il.com>, Xiang Gao <gxxa03070307@...il.com>
Cc: "sumit.semwal@...aro.org" <sumit.semwal@...aro.org>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"mhiramat@...nel.org" <mhiramat@...nel.org>,
"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"mathieu.desnoyers@...icios.com" <mathieu.desnoyers@...icios.com>,
"dhowells@...hat.com" <dhowells@...hat.com>,
"kuba@...nel.org" <kuba@...nel.org>, "brauner@...nel.org"
<brauner@...nel.org>, "akpm@...ux-foundation.org"
<akpm@...ux-foundation.org>,
"linux-trace-kernel@...r.kernel.org" <linux-trace-kernel@...r.kernel.org>
Subject: Re: 答复: [External Mail]Re: [PATCH v4] dma-buf: add some tracepoints to debug.
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@...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
> *主题:* 答复: [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@....com>
> *发送时间:* 2025年11月28日 17:39:31
> *收件人:* Barry Song; Xiang Gao
> *抄送:* 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; 高翔
> *主题:* [External Mail]Re: [PATCH v4] dma-buf: add some tracepoints to debug.
>
> [外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给misec@...omi.com进行反馈
>
> 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.
>
Powered by blists - more mailing lists