Re: [PATCH v13 bpf-next 1/1] rethook: x86: Add rethook x86 implementation

From: Masami Hiramatsu
Date: Wed Mar 23 2022 - 11:15:00 EST


On Wed, 23 Mar 2022 13:34:54 +0100
Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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@xxxxxxxxxx/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@xxxxxxxxxx>