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>
