[PATCH v2 00/12] tracing/probe: Add multi-probes per event support

Masami Hiramatsu
2019-06-19T15:07:17Z

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

Thank you,

---

Masami Hiramatsu (12):
tracing/probe: Split trace_event related data from trace_probe
tracing/dynevent: Delete all matched events
tracing/dynevent: Pass extra arguments to match operation
tracing/kprobe: Add multi-probe per event support
tracing/uprobe: Add multi-probe per uprobe event support
tracing/kprobe: Add per-probe delete from event
tracing/uprobe: Add per-probe delete from event
tracing/probe: Add immediate parameter support
tracing/probe: Add immediate string parameter support
selftests/ftrace: Add a testcase for kprobe multiprobe event
selftests/ftrace: Add syntax error test for immediates
selftests/ftrace: Add syntax error test for multiprobe

Documentation/trace/kprobetrace.rst | 1
Documentation/trace/uprobetracer.rst | 1
kernel/trace/trace.c | 8 -
kernel/trace/trace_dynevent.c | 10 +
kernel/trace/trace_dynevent.h | 7 -
kernel/trace/trace_events_hist.c | 4
kernel/trace/trace_kprobe.c | 241 ++++++++++++++----
kernel/trace/trace_probe.c | 176 +++++++++++--
kernel/trace/trace_probe.h | 67 ++++-
kernel/trace/trace_uprobe.c | 263 +++++++++++++++-----
tools/testing/selftests/ftrace/test.d/functions | 2
.../ftrace/test.d/kprobe/kprobe_multiprobe.tc | 35 +++
.../ftrace/test.d/kprobe/kprobe_syntax_errors.tc | 15 +
13 files changed, 665 insertions(+), 165 deletions(-)
create mode 100644 tools/testing/selftests/ftrace/test.d/kprobe/kprobe_multiprobe.tc

--
Masami Hiramatsu (Linaro) <mhiramat@kernel.org>