On Wed, 24 Jan 2024 10:46:10 +0800
"yebin (H)" <yebi...@huawei.com> wrote:
>
>
> On 2024/1/23 22:40, Masami Hiramatsu (Google) wrote:
> > On Tue, 23 Jan 2024 17:21:35 +0800
> > Ye Bin <yebi...@huawei.com> wrote:
> >
> >> Similar to '%pd' for printk, use '%pd' for print struct dentry's name.
> >>
> >> Signed-off-by: Ye Bin <yebi...@huawei.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) <mhira...@kernel.org>
