| Message ID | 20240119013848.3111364-1-yebin10@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | support '%pd' and '%pD' for print file name | expand |
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. >