ok, thank you for your guidance. ________________________________ 发件人: Steven Rostedt <[email protected]> 发送时间: 2025年12月27日 0:42:15 收件人: Xiang Gao 抄送: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; 高翔 主题: [External Mail]Re: [PATCH v11] dma-buf: add some tracepoints to debug.
[外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给[email protected]进行反馈 On Thu, 25 Dec 2025 20:11:19 +0800 Xiang Gao <[email protected]> wrote: > From: gaoxiang17 <[email protected]> > > 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:3016_1-3102 [006] ...1. 255.126521: dma_buf_export: > exp_name=qcom,system size=12685312 ino=2738 > binder:3016_1-3102 [006] ...1. 255.126528: dma_buf_fd: > exp_name=qcom,system size=12685312 ino=2738 fd=8 > binder:3016_1-3102 [006] ...1. 255.126642: dma_buf_mmap_internal: > exp_name=qcom,system size=28672 ino=2739 > kworker/6:1-86 [006] ...1. 255.127194: dma_buf_put: > exp_name=qcom,system size=12685312 ino=2738 > RenderThread-9293 [006] ...1. 316.618179: dma_buf_get: > exp_name=qcom,system size=12771328 ino=2762 fd=176 > RenderThread-9293 [006] ...1. 316.618195: dma_buf_dynamic_attach: > exp_name=qcom,system size=12771328 ino=2762 attachment:ffffff880a18dd00 > is_dynamic=0 dev_name=kgsl-3d0 > RenderThread-9293 [006] ...1. 318.878220: dma_buf_detach: > exp_name=qcom,system size=12771328 ino=2762 attachment:ffffff880a18dd00 > is_dynamic=0 dev_name=kgsl-3d0 > > Signed-off-by: Xiang Gao <[email protected]> > --- > > Changes since v10: > https://lore.kernel.org/all/[email protected]/ You only need to show the last revision (but since you haven't showed the others, before it's good to show them now). But you also want to say "what changed" For example: - Used DEFINE_EVENT_CONDITION() to move the condition branch into the tracepoint. > Changes since v9: > https://lore.kernel.org/all/[email protected]/ > Changes since v8: > https://lore.kernel.org/all/[email protected]/ > Changes since v7: > https://lore.kernel.org/all/[email protected]/ > Changes since v6: > https://lore.kernel.org/all/[email protected]/ > Changes since v5: > https://lore.kernel.org/all/[email protected]/ > Changes since v4: > https://lore.kernel.org/all/[email protected]/ > Changes since v3: > https://lore.kernel.org/all/[email protected]/ > Changes since v2: > https://lore.kernel.org/all/[email protected]/ > Changes since v1: > https://lore.kernel.org/all/[email protected]/ > > drivers/dma-buf/dma-buf.c | 48 +++++++++- > include/trace/events/dma_buf.h | 159 +++++++++++++++++++++++++++++++++ > 2 files changed, 205 insertions(+), 2 deletions(-) > create mode 100644 include/trace/events/dma_buf.h > > +/* > + * dmabuf->name must be accessed with holding dmabuf->name_lock. > + * we need to take the lock around the tracepoint call itself where > + * it is called in the code. > + * > + * Note: FUNC##_enabled() is a static branch that will only > + * be set when the trace event is enabled. > + */ > +#define DMA_BUF_TRACE(FUNC, ...) \ > + do { \ > + /* Always expose lock if lockdep is enabled */ \ > + if (IS_ENABLED(CONFIG_LOCKDEP) || FUNC##_enabled()) { \ > + guard(spinlock)(&dmabuf->name_lock); \ > + FUNC(__VA_ARGS__); \ > + } \ > + } while (0) > + > static inline int is_dma_buf_file(struct file *); > > + > +DEFINE_EVENT_CONDITION(dma_buf_fd, dma_buf_fd, > + > + TP_PROTO(struct dma_buf *dmabuf, int fd), > + > + TP_ARGS(dmabuf, fd), > + > + TP_CONDITION(fd >= 0) > +); > + From a tracing point of view (It's up to the dma maintainers to decide to take this patch): Reviewed-by: Steven Rostedt (Google) <[email protected]> -- Steve
