[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240119234356.1598e760edbfa58f5440a941@kernel.org>
Date: Fri, 19 Jan 2024 23:43:56 +0900
From: Masami Hiramatsu (Google) <mhiramat@...nel.org>
To: Ye Bin <yebin10@...wei.com>
Cc: <rostedt@...dmis.org>, <mathieu.desnoyers@...icios.com>,
<linux-trace-kernel@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] support '%pd' and '%pD' for print file name
On Fri, 19 Jan 2024 09:38:45 +0800
Ye Bin <yebin10@...wei.com> wrote:
> During fault locating, the file name needs to be printed based on the
> dentry/file address. The offset needs to be calculated each time, which
> is troublesome. Similar to printk, kprobe supports printing file names
> for dentry/file addresses.
Hi Ye,
Thanks for your proposal!
Generically, I think this type of hack is not good for the tracing
because there are already some ways to do that. e.g.
- Use perf probe to specify dentry->name:string or file->name:string
- Use BTF to specify in the same way (but only for function entry)
And those are more obvious what it does.
However, if this is implemented in more generic syntax, it will be
acceptable.
For example, type specifying with "arg1:printfmt(%pD)" will be
more generic because it is apparently one of the printfmt and output
string. Or, maybe we can just allow to use ":%pD" as a fetch type
(start with '%' means the printfmt)
Also, could you update readme_msg[] in kernel/trace/trace.c if
you add a type, and add a testcase of selftests/ftrace, for this
feature? Documentation should also be updated with more syntax
information.
Thank you,
>
> Ye Bin (3):
> tracing/probes: support '%pd' type for print struct dentry's name
> tracing/probes: support '%pD' type for print struct file's name
> Documentation: tracing: add new type 'pd' and 'pD' for kprobe
>
> Documentation/trace/kprobetrace.rst | 3 +-
> kernel/trace/trace_probe.c | 50 +++++++++++++++++++++++++++++
> 2 files changed, 52 insertions(+), 1 deletion(-)
>
> --
> 2.31.1
>
--
Masami Hiramatsu (Google) <mhiramat@...nel.org>
Powered by blists - more mailing lists