[0/3] support '%pd' and '%pD' for print file name

  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.

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(-)
  

On Fri, 19 Jan 2024 09:38:45 +0800
Ye Bin <yebin10@huawei.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
>
  

On Fri, 19 Jan 2024 23:43:56 +0900
Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:

> 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)

Yes, I like this idea a lot. Please add the '%' keyword/token to change how
to display this in the print format.

We may need to add more than one token though. Is that supported?

  $arg1:u32:%08x

or that could also be:

  $arg1:%08x:u32

That is, the order should not be important.

Thoughts?

-- Steve


> 
> 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.
  

On 2024/1/19 22:43, Masami Hiramatsu (Google) wrote:
> On Fri, 19 Jan 2024 09:38:45 +0800
> Ye Bin <yebin10@huawei.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,
Thank you very much for your suggestion.
I will re-implement this function according to your suggestion.
>> 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
>>
>
  

On Fri, 19 Jan 2024 10:52:43 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Fri, 19 Jan 2024 23:43:56 +0900
> Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
> 
> > 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)
> 
> Yes, I like this idea a lot. Please add the '%' keyword/token to change how
> to display this in the print format.
> 
> We may need to add more than one token though. Is that supported?
> 
>   $arg1:u32:%08x
> 
> or that could also be:
> 
>   $arg1:%08x:u32

No, not yet. But I rather like comma separated.

$arg1:u32,%08x

Hm, this needs more changes, like a new type parser. And it will be
a option of the default type.

Thank you, 

> 
> That is, the order should not be important.
> 
> Thoughts?
> 
> -- Steve
> 
> 
> > 
> > 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.
>