All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org,
	Tom Zanussi <tom.zanussi@linux.intel.com>,
	Ravi Bangoria <ravi.bangoria@linux.ibm.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>
Subject: Re: [PATCH v2 00/12] tracing/probe: Add multi-probes per event support
Date: Thu, 1 Aug 2019 23:01:17 +0900	[thread overview]
Message-ID: <20190801230117.c415b1052cb271fcd4eb56b6@kernel.org> (raw)
In-Reply-To: <20190731112539.1efac604@gandalf.local.home>

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

> On Thu, 20 Jun 2019 00:07:09 +0900
> Masami Hiramatsu <mhiramat@kernel.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@kernel.org>

      reply	other threads:[~2019-08-01 14:01 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-19 15:07 [PATCH v2 00/12] tracing/probe: Add multi-probes per event support Masami Hiramatsu
2019-06-19 15:07 ` [PATCH v2 01/12] tracing/probe: Split trace_event related data from trace_probe Masami Hiramatsu
2019-06-19 15:07 ` [PATCH v2 02/12] tracing/dynevent: Delete all matched events Masami Hiramatsu
2019-06-19 15:07 ` [PATCH v2 03/12] tracing/dynevent: Pass extra arguments to match operation Masami Hiramatsu
2019-06-19 15:07 ` [PATCH v2 04/12] tracing/kprobe: Add multi-probe per event support Masami Hiramatsu
2019-06-19 15:07 ` [PATCH v2 05/12] tracing/uprobe: Add multi-probe per uprobe " Masami Hiramatsu
2019-06-19 15:08 ` [PATCH v2 06/12] tracing/kprobe: Add per-probe delete from event Masami Hiramatsu
2019-06-19 15:08 ` [PATCH v2 07/12] tracing/uprobe: " Masami Hiramatsu
2019-06-19 15:08 ` [PATCH v2 08/12] tracing/probe: Add immediate parameter support Masami Hiramatsu
2019-06-19 15:08 ` [PATCH v2 09/12] tracing/probe: Add immediate string " Masami Hiramatsu
2019-06-19 15:08 ` [PATCH v2 10/12] selftests/ftrace: Add a testcase for kprobe multiprobe event Masami Hiramatsu
2019-06-19 15:08 ` [PATCH v2 11/12] selftests/ftrace: Add syntax error test for immediates Masami Hiramatsu
2019-06-19 15:09 ` [PATCH v2 12/12] selftests/ftrace: Add syntax error test for multiprobe Masami Hiramatsu
2019-07-04  6:39 ` [PATCH v2 00/12] tracing/probe: Add multi-probes per event support Masami Hiramatsu
2019-07-04 11:28   ` Steven Rostedt
2019-07-30  6:23     ` Masami Hiramatsu
2019-07-30 15:03       ` Steven Rostedt
2019-07-31 15:25 ` Steven Rostedt
2019-08-01 14:01   ` Masami Hiramatsu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190801230117.c415b1052cb271fcd4eb56b6@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=acme@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=ravi.bangoria@linux.ibm.com \
    --cc=rostedt@goodmis.org \
    --cc=tom.zanussi@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.