From: Masami Hiramatsu <mhiramat@kernel.org>
To: Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii.nakryiko@gmail.com>,
x86@kernel.org, Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Dan Carpenter <dan.carpenter@oracle.com>,
kernel-janitors@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Jiri Olsa <jolsa@kernel.org>,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH bpf-next 0/2] kprobes: rethook: x86: Replace kretprobe trampoline with rethook
Date: Fri, 25 Mar 2022 13:28:39 +0900 [thread overview]
Message-ID: <164818251899.2252200.7306353689206167903.stgit@devnote2> (raw)
Hi,
Here are the patch set for generic kretprobe and kretprobe on x86 for
replacing the kretprobe trampoline with rethook. For the other archs,
I will port rethook to those after this has been merged.
This is previously called as "rethook: x86: Add rethook x86 implementation"
The previous thread is here[1].
[1] https://lore.kernel.org/all/164800288611.1716332.7053663723617614668.stgit@devnote2/T/#u
Background:
This rethook came from Jiri's request of multiple kprobe for bpf[1].
He tried to solve an issue that starting bpf with multiple kprobe will
take a long time because bpf-kprobe will wait for RCU grace period for
sync rcu events.
Jiri wanted to attach a single bpf handler to multiple kprobes and
he tried to introduce multiple-probe interface to kprobe. So I asked
him to use ftrace and kretprobe-like hook if it is only for the
function entry and exit, instead of adding ad-hoc interface
to kprobes.
For this purpose, I introduced the fprobe (kprobe like interface for
ftrace) with the rethook (this is a generic return hook feature for
fprobe exit handler)[2].
[1] https://lore.kernel.org/all/20220104080943.113249-1-jolsa@kernel.org/T/#u
[2] https://lore.kernel.org/all/164191321766.806991.7930388561276940676.stgit@devnote2/T/#u
The rethook is basically same as the kretprobe trampoline. I just made
it decoupled from kprobes. Eventually, the all arch dependent kretprobe
trampolines will be replaced with the rethook trampoline instead of
cloning and set HAVE_RETHOOK=y.
When I port the rethook for all arch which supports kretprobe, the
legacy kretprobe specific code (which is for CONFIG_KRETPROBE_ON_RETHOOK=n)
will be removed eventually.
BTW, this patch can be applied to next-20220324, not the bpf-next tree
directly, because this depends on ANNOTATE_NOENDBR macro. However, since
the fprobe is merged in the bpf-next, I marked this for bpf-next.
So until merging the both of fprobes and ENDBR series, to compile this
you need below 2 lines in arch/x86/kernel/rethook.c.
#ifndef ANNOTATE_NOENDBR
#define ANNOTATE_NOENDBR
But after those are merged, these lines will be unneeded. How should I
handle this issue? (Just remove ANNOTATE_NOENDBR line in bpf-next?)
Thank you,
---
Masami Hiramatsu (2):
kprobes: Use rethook for kretprobe if possible
rethook: kprobes: x86: Replace kretprobe with rethook on x86
arch/Kconfig | 7 ++
arch/x86/Kconfig | 1
arch/x86/include/asm/unwind.h | 23 +++----
arch/x86/kernel/Makefile | 1
arch/x86/kernel/kprobes/common.h | 1
arch/x86/kernel/kprobes/core.c | 107 ---------------------------------
arch/x86/kernel/rethook.c | 121 +++++++++++++++++++++++++++++++++++++
include/linux/kprobes.h | 51 +++++++++++++++-
kernel/kprobes.c | 124 ++++++++++++++++++++++++++++++++------
kernel/trace/trace_kprobe.c | 4 +
10 files changed, 296 insertions(+), 144 deletions(-)
create mode 100644 arch/x86/kernel/rethook.c
--
Masami Hiramatsu (Linaro) <mhiramat@kernel.org>
next reply other threads:[~2022-03-25 4:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-25 4:28 Masami Hiramatsu [this message]
2022-03-25 4:28 ` [PATCH bpf-next 1/2] kprobes: Use rethook for kretprobe if possible Masami Hiramatsu
2022-03-25 4:29 ` [PATCH bpf-next 2/2] rethook: kprobes: x86: Replace kretprobe with rethook on x86 Masami Hiramatsu
2022-03-25 10:09 ` Peter Zijlstra
2022-03-25 11:51 ` Jiri Olsa
2022-03-25 12:56 ` Masami Hiramatsu
2022-03-25 10:11 ` Peter Zijlstra
2022-03-25 11:40 ` [PATCH bpf-next 3/2] x86,rethook: Fix arch_rethook_trampoline() to generate a complete pt_regs Peter Zijlstra
2022-03-25 13:01 ` Masami Hiramatsu
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=164818251899.2252200.7306353689206167903.stgit@devnote2 \
--to=mhiramat@kernel.org \
--cc=andrii.nakryiko@gmail.com \
--cc=ast@kernel.org \
--cc=bp@alien8.de \
--cc=bpf@vger.kernel.org \
--cc=dan.carpenter@oracle.com \
--cc=dave.hansen@linux.intel.com \
--cc=jolsa@kernel.org \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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.