Messages in this thread | | | From | Andrii Nakryiko <> | Date | Thu, 17 Mar 2022 15:03:33 -0700 | Subject | Re: [for-next][PATCH 03/13] fprobe: Add ftrace based probe APIs |
| |
On Thu, Mar 17, 2022 at 8:25 AM Steven Rostedt <rostedt@goodmis.org> wrote: > > From: Masami Hiramatsu <mhiramat@kernel.org> > > The fprobe is a wrapper API for ftrace function tracer. > Unlike kprobes, this probes only supports the function entry, but this > can probe multiple functions by one fprobe. The usage is similar, user > will set their callback to fprobe::entry_handler and call > register_fprobe*() with probed functions. > There are 3 registration interfaces, > > - register_fprobe() takes filtering patterns of the functin names. > - register_fprobe_ips() takes an array of ftrace-location addresses. > - register_fprobe_syms() takes an array of function names. > > The registered fprobes can be unregistered with unregister_fprobe(). > e.g. > > struct fprobe fp = { .entry_handler = user_handler }; > const char *targets[] = { "func1", "func2", "func3"}; > ... > > ret = register_fprobe_syms(&fp, targets, ARRAY_SIZE(targets)); > > ... > > unregister_fprobe(&fp); > > Link: https://lkml.kernel.org/r/164735283857.1084943.1154436951479395551.stgit@devnote2 > > Cc: Jiri Olsa <jolsa@kernel.org> > Cc: Alexei Starovoitov <ast@kernel.org> > Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com> > Cc: Daniel Borkmann <daniel@iogearbox.net> > Cc: Andrii Nakryiko <andrii@kernel.org> > Cc: Martin KaFai Lau <kafai@fb.com> > Cc: Song Liu <songliubraving@fb.com> > Cc: Yonghong Song <yhs@fb.com> > Cc: John Fastabend <john.fastabend@gmail.com> > Cc: KP Singh <kpsingh@chromium.org> > Cc: "Naveen N . Rao" <naveen.n.rao@linux.ibm.com> > Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> > Cc: "David S . Miller" <davem@davemloft.net> > Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> > Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> > ---
Hey Steven!
Do I understand correctly that this patch set was applied in your tree? I was under the impression that we agreed to route this through the bpf-next tree earlier (see [0]), but I might have misunderstood something, sorry.
Either way, the reason it matters is because Jiri's multi-attach kprobe patch set ([1]) is depending on Masami's patches and having fprobe patches in bpf-next tree would simplify logistics significantly.
So I wonder if it's still possible to route it through bpf-next?
If not, we'd need a way to get these changes into the bpf-next tree somehow. Having it in a separate branch that we can merge would be a way to go about this, I presume? But it's certainly a more complicated way, so it would be preferable to back it out and land through bpf-next.
Please let me know how we should proceed. Thanks!
[0] https://lore.kernel.org/bpf/CAEf4BzaugZWf6f_0JzA-mqaGfp52tCwEp5dWdhpeVt6GjDLQ3Q@mail.gmail.com/ [1] https://lore.kernel.org/bpf/20220316122419.933957-1-jolsa@kernel.org/
> include/linux/fprobe.h | 87 +++++++++++++++++ > kernel/trace/Kconfig | 12 +++ > kernel/trace/Makefile | 1 + > kernel/trace/fprobe.c | 211 +++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 311 insertions(+) > create mode 100644 include/linux/fprobe.h > create mode 100644 kernel/trace/fprobe.c >
[...]
| |