On Wed, 9 Aug 2023 17:45:29 +0200 Florent Revest <revest@xxxxxxxxxxxx> wrote: > On Wed, Aug 9, 2023 at 4:43 PM Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote: > > > > > I think there are two things that can be meant with "rethook uses ftrace_regs": > > > > > > - rethook callbacks receive a ftrace_regs (that's what you do further down) > > > - rethook can hook to a traced function using a ftrace_regs (that's > > > what you use in fprobe now) > > > > > > But I think the second proposition shouldn't imply that rethook_hook > > > can _only_ hook to ftrace_regs. For the kprobe use case, I think there > > > should also be a rethook_hook_pt_regs() that operates on a pt_regs. We > > > could have a default implementation of rethook_hook that calls into > > > the other (or vice versa) on HAVE_FTRACE_REGS_COMPATIBLE_WITH_PT_REGS > > > but I think it's good to separate these two APIs > > > > Yeah, so for simplying the 2nd case, I added this dependency. > > > > diff --git a/arch/Kconfig b/arch/Kconfig > > index aff2746c8af2..e321bdb8b22b 100644 > > --- a/arch/Kconfig > > +++ b/arch/Kconfig > > @@ -201,6 +201,7 @@ config KRETPROBE_ON_RETHOOK > > def_bool y > > depends on HAVE_RETHOOK > > depends on KRETPROBES > > + depends on HAVE_PT_REGS_COMPAT_FTRACE_REGS || !HAVE_DYNAMIC_FTRACE_WITH_ARGS > > select RETHOOK > > > > This is the point why I said that "do not remove kretprobe trampoline". > > If there is arch dependent kretprobe trampoline, kretprobe does not use > > the rethook for hooking return. And eventually I would like to remove > > kretprobe itself (replace it with fprobe + rethook). If so, I don't want > > to pay more efforts on this part, and keep kretprobe on rethook as it is. > > What are your thoughts on kprobe + rethook though ? Isn't it KRETPROBE_ON_RETHOOK? > If that's something you think is worth having, then in this case, it > seems that having a rethook_hook_pt_regs() API would help users. > > If that's a frankenstein use case you don't want to support then I > agree we can live without this API and get away with the cast > protected by the depends on HAVE_PT_REGS_COMPAT_FTRACE_REGS... Yeah, it needs to introduce arch_rethook_prepare_pt_regs() for each arch too. BTW, I found that I have to update the implementation of arch_rethook_prepare() for x86. (Use ftrace_get_stack_pointer()) Thank you! -- Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
