linux-kernel - Re: [PATCH v4 3/7] tracing/probes: support '%pd' type for print struct dentry's name

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 24 Jan 2024 21:27:38 +0900
From: Masami Hiramatsu (Google) <mhiramat@...nel.org>
To: "yebin (H)" <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 v4 3/7] tracing/probes: support '%pd' type for print
 struct dentry's name

On Wed, 24 Jan 2024 10:46:10 +0800
"yebin (H)" <yebin10@...wei.com> wrote:

> 
> 
> On 2024/1/23 22:40, Masami Hiramatsu (Google) wrote:
> > On Tue, 23 Jan 2024 17:21:35 +0800
> > Ye Bin <yebin10@...wei.com> wrote:
> >
> >> Similar to '%pd' for printk, use '%pd' for print struct dentry's name.
> >>
> >> Signed-off-by: Ye Bin <yebin10@...wei.com>
> >> ---
> >>   kernel/trace/trace_kprobe.c | 6 ++++++
> >>   kernel/trace/trace_probe.h  | 1 +
> >>   2 files changed, 7 insertions(+)
> >>
> >> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> >> index c4c6e0e0068b..00b74530fbad 100644
> >> --- a/kernel/trace/trace_kprobe.c
> >> +++ b/kernel/trace/trace_kprobe.c
> >> @@ -779,6 +779,7 @@ static int __trace_kprobe_create(int argc, const char *argv[])
> >>   	char buf[MAX_EVENT_NAME_LEN];
> >>   	char gbuf[MAX_EVENT_NAME_LEN];
> >>   	char abuf[MAX_BTF_ARGS_LEN];
> >> +	char dbuf[MAX_DENTRY_ARGS_LEN];
> > Hmm, no, I don't like to expand stack anymore. Please allocate it
> > from heap.
> Do I need to change the other buffers on the stacks to allocate memory 
> from heap?

No, that is not needed for this series, but if you want, you can :)

> >>   	struct traceprobe_parse_context ctx = { .flags = TPARG_FL_KERNEL };
> >>   
> >>   	switch (argv[0][0]) {
> >> @@ -930,6 +931,11 @@ static int __trace_kprobe_create(int argc, const char *argv[])
> >>   		argv = new_argv;
> >>   	}
> >>   
> >> +	ret = traceprobe_expand_dentry_args(argc, argv, dbuf,
> >> +					    MAX_DENTRY_ARGS_LEN);
> >> +	if (ret)
> >> +		goto out;
> > And calling this here will not cover the trace_fprobe.
> >
> > Could you call this from traceprobe_expand_meta_args() instead of
> > calling it directly from trace_kprobe? Then it can be used from
> > fprobe_event too.
> >
> > Thank you,
> At first I wanted to implement the extension logic in 
> traceprobe_expand_meta_args(),
> but I found that the code was difficult to understand when I started 
> writing.

Yeah, I also found that is a bit different usage.

> If fprobe_event
> wants to support this function, is traceprobe_expand_dentry_args() also 
> called?

Yes, it is for expanding '$arg*' into '$arg1 $arg2 ...'

> Or re-encapsulate
> an interface to include the logic of different extensions. In this way, 
> the same buffer is used for
> the entire extension process, and the extension function needs to return 
> the information about
> the length of the buffer.

OK, I confirmed that will be too much complicated. Then can you just call
it from where the traceprobe_expand_meta_args() is called, which is 
__trace_fprobe_create()@trace_fprobe.c ?

But those should be simplified later.

Thank you,

-- 
Masami Hiramatsu (Google) <mhiramat@...nel.org>