Messages in this thread | | | Date | Thu, 24 Mar 2022 00:14:48 +0900 | From | Masami Hiramatsu <> | Subject | Re: [PATCH v13 bpf-next 1/1] rethook: x86: Add rethook x86 implementation |
| |
On Wed, 23 Mar 2022 13:34:54 +0100 Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, Mar 23, 2022 at 08:41:19PM +0900, Masami Hiramatsu wrote: > > > > Also, what's rethook for anyway? > > > > Rethook is a feature which hooks the function return. Most of the > > logic came from the kretprobe. Simply to say, 'kretprobe - kprobe' is > > the rethook :) > > I got that far, but why did you take the bother to do these patches? Why > wasn't 'use kretprobe' a good enough option?
Ah, sorry about lacking the background story.
Actually this 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. So I introduced fprobe (kprobe like interface for ftrace) and 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
This is the reason why I need to split the kretprobe's trampoline as rethook. Kretprobe is only for probing a single function entry/exit, thus it does not suit for this purpose.
Thank you,
-- Masami Hiramatsu <mhiramat@kernel.org>
| |