Message-Id: <20190801230117.c415b1052cb271fcd4eb56b6@kernel.org>
Date:   Thu, 1 Aug 2019 23:01:17 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
        Tom Zanussi <tom.zanussi@...ux.intel.com>,
        Ravi Bangoria <ravi.bangoria@...ux.ibm.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: Re: [PATCH v2 00/12] tracing/probe: Add multi-probes per event
 support

On Wed, 31 Jul 2019 11:25:39 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:

> On Thu, 20 Jun 2019 00:07:09 +0900
> Masami Hiramatsu <mhiramat@...nel.org> wrote:
> 
> > Hello,
> > 
> > This is the 2nd version of multi-probes per event support on ftrace
> > and perf-tools.
> > 
> > Previous version is here;
> > https://lkml.org/lkml/2019/5/31/573
> > 
> > >From this version, I omitted first 9 patches which has been picked  
> > to Steve's tree.
> > In this version, I've fixed some bugs and hardened some unexpected
> > error cases according to Steve's comment.
> > Here are changes in this version:
> > 
> >  - [1/12] This have below changes. 
> >     - Warn if the primary trace_probe does not exist.
> >     - Fix enable_trace_kprobe() to not return error if the any probes
> >       are "gone" state. If all probes have gone or any other error
> >       reason, the event can not be enabled and return error.
> >     - Fix trace_probe_enable() to roll back all enabled uprobe if
> >       any one of uprobe is failed to enable.
> >  - [7/12] Swap the checking order of filename for avoiding unexpected
> >      memory access.
> > 
> > 
> > ====
> > For trace-event, we can insert same trace-event on several places
> > on the code, and those can record similar information as a same event
> > with same format.
> > 
> > This series implements similar feature on probe-event. Since the probe
> > event is based on the compiled binary, sometimes we find that the target
> > source line is complied into several different addresses, e.g. inlined
> > function, unrolled loop, etc. In those cases, it is useful to put a
> > same probe-event on different addresses.
> > 
> > With this series, we can append multi probes on one event as below
> > 
> >   # echo p:testevent _do_fork r1=%ax r2=%dx > kprobe_events
> >   # echo p:testevent fork_idle r1=%ax r2=%cx >> kprobe_events
> >   # kprobe_events
> >   p:kprobes/testevent _do_fork r1=%ax r2=%dx
> >   p:kprobes/testevent fork_idle r1=%ax r2=%cx
> > 
> > This means testevent is hit on both of _do_fork and fork_idle.
> > As you can see, the appended event must have same number of arguments
> > and those must have same 'type' and 'name' as original one. This is like
> > a function signature, it checks whether the appending event has the same
> > type and name of event arguments and same probe type, but doesn't care
> > about the assignment.
> > 
> > So, below appending commands will be rejected.
> > 
> >   # echo p:testevent _do_fork r1=%ax r2=%dx > kprobe_events
> >   # echo p:testevent fork_idle r1=%ax >> kprobe_events
> >   (No 2nd argument)
> >   # echo p:testevent fork_idle r1=%ax r2=%ax:x8 >> kprobe_events
> >   (The type of 2nd argument is different)
> > 
> > If one inlined code has an argument on a register, but another
> > inlined code has fixed value (as a result of optimization),
> > you can also specify the fixed immediate value, e.g.
> > 
> >   # echo p:testevent _do_fork r1=%ax r2=%dx > kprobe_events
> >   # echo p:testevent fork_idle r1=%ax r2=\1 >> kprobe_events
> > 
> > 
> 
> 
> Hi Masami,
> 
> I applied this patch set to my queue. Nice feature! I'll probably be
> testing it a bit more. I wont be pushing it to my repo until v5.3-rc3
> comes out, as I'll plan on rebasing my for-next branch on that.

Thanks! if there is any issue, please let me know.
I also start working on perf probe part to support this.

Thank you,

> 
> Thanks!
> 
> -- Steve


-- 
Masami Hiramatsu <mhiramat@...nel.org>

Powered by blists - more mailing lists