| Message ID | 20171130235023.1414663-1-songliubraving@fb.com |
|---|---|
| Headers | show |
| Series | enable creating [k,u]probe with perf_event_open | expand |
On 12/01/2017 12:50 AM, Song Liu wrote: > Changes PATCH v2 to PATCH v3: > Remove fixed type PERF_TYPE_KPROBE and PERF_TYPE_UPROBE, use dynamic > type instead. > Update userspace (samples/bpf, bcc) to look up type from sysfs. > Change License info in test_many_kprobe_user.c as Philippe Ombredanne > suggested. > > Changes PATCH v1 to PATCH v2: > Split PERF_TYPE_PROBE into PERF_TYPE_KPROBE and PERF_TYPE_UPROBE. > Split perf_probe into perf_kprobe and perf_uprobe. > Remove struct probe_desc, use config1 and config2 instead. > > Changes RFC v2 to PATCH v1: > Check type PERF_TYPE_PROBE in perf_event_set_filter(). > Rebase on to tip perf/core. > > Changes RFC v1 to RFC v2: > Fix build issue reported by kbuild test bot by adding ifdef of > CONFIG_KPROBE_EVENTS, and CONFIG_UPROBE_EVENTS. > > RFC v1 cover letter: > > This is to follow up the discussion over "new kprobe api" at Linux > Plumbers 2017: > > https://www.linuxplumbersconf.org/2017/ocw/proposals/4808 > > With current kernel, user space tools can only create/destroy [k,u]probes > with a text-based API (kprobe_events and uprobe_events in tracefs). This > approach relies on user space to clean up the [k,u]probe after using them. > However, this is not easy for user space to clean up properly. > > To solve this problem, we introduce a file descriptor based API. > Specifically, we extended perf_event_open to create [k,u]probe, and attach > this [k,u]probe to the file descriptor created by perf_event_open. These > [k,u]probe are associated with this file descriptor, so they are not > available in tracefs. > > We reuse large portion of existing trace_kprobe and trace_uprobe code. > Currently, the file descriptor API does not support arguments as the > text-based API does. This should not be a problem, as user of the file > decriptor based API read data through other methods (bpf, etc.). > > I also include a patch to to bcc, and a patch to man-page perf_even_open. > Please see the list below. A fork of bcc with this patch is also available > on github: > > https://github.com/liu-song-6/bcc/tree/perf_event_open How should this set be routed? The majority of changes are in core tracing, so I guess taking that route as well would make most sense here. bpf_load.[ch] changes could potentially make surgery necessary later on, would it make sense to pull only the two samples plus tools/include/uapi commit then into bpf-next via pull-req after they are considered fine and got applied from Peter/Steven? Presumably git would handle this workflow fine, thus pull-req could avoid the duplicate patch issue we had recently? I'm also okay if the whole series goes via tracing and if we indeed get into the situation, we just fix up any merge conflicts under samples. > Thanks, > Song > > man-pages patch: > perf_event_open.2: add type kprobe and uprobe > > bcc patch: > bcc: Try use new API to create [k,u]probe with perf_event_open > > kernel patches: > > Song Liu (6): > perf: prepare perf_event.h for new types perf_kprobe and perf_uprobe > perf: copy new perf_event.h to tools/include/uapi > perf: implement pmu perf_kprobe > perf: implement pmu perf_uprobe > bpf: add option for bpf_load.c to use perf_kprobe > bpf: add new test test_many_kprobe > > include/linux/trace_events.h | 4 + > include/uapi/linux/perf_event.h | 6 ++ > kernel/events/core.c | 81 ++++++++++++++- > kernel/trace/trace_event_perf.c | 111 ++++++++++++++++++++ > kernel/trace/trace_kprobe.c | 91 +++++++++++++++-- > kernel/trace/trace_probe.h | 11 ++ > kernel/trace/trace_uprobe.c | 86 ++++++++++++++-- > samples/bpf/Makefile | 3 + > samples/bpf/bpf_load.c | 63 ++++++++++-- > samples/bpf/bpf_load.h | 14 +++ > samples/bpf/test_many_kprobe_user.c | 186 ++++++++++++++++++++++++++++++++++ > tools/include/uapi/linux/perf_event.h | 6 ++ > 12 files changed, 633 insertions(+), 29 deletions(-) > create mode 100644 samples/bpf/test_many_kprobe_user.c > > -- > 2.9.5 >