On Wed, Aug 9, 2023 at 6:09 PM Florent Revest <revest@xxxxxxxxxxxx> wrote: > > On Wed, Aug 9, 2023 at 4:10 PM Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote: > > > > Hi Florent, > > > > On Wed, 9 Aug 2023 12:28:38 +0200 > > Florent Revest <revest@xxxxxxxxxxxx> wrote: > > > > > On Mon, Aug 7, 2023 at 8:48 AM Masami Hiramatsu (Google) > > > <mhiramat@xxxxxxxxxx> wrote: > > > > > > > > From: Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx> > > > > > > > > This allows fprobes to be available with CONFIG_DYNAMIC_FTRACE_WITH_ARGS > > > > instead of CONFIG_DYNAMIC_FTRACE_WITH_REGS, then we can enable fprobe > > > > on arm64. > > > > > > This patch lets fprobe code build on configs WITH_ARGS and !WITH_REGS > > > but fprobe wouldn't run on these builds because fprobe still registers > > > to ftrace with FTRACE_OPS_FL_SAVE_REGS, which would fail on > > > !WITH_REGS. Shouldn't we also let the fprobe_init callers decide > > > whether they want REGS or not ? > > > > Ah, I think you meant FPROBE_EVENTS? Yes I forgot to add the dependency > > on it. But fprobe itself can work because fprobe just pass the ftrace_regs > > to the handlers. (Note that exit callback may not work until next patch) > > No, I mean that fprobe still registers its ftrace ops with the > FTRACE_OPS_FL_SAVE_REGS flag: > > https://git.kernel.org/pub/scm/linux/kernel/git/mhiramat/linux.git/tree/kernel/trace/fprobe.c?h=topic/fprobe-ftrace-regs&id=2ca022b2753ae0d2a2513c95f7ed5b5b727fb2c4#n185 > > Which means that __register_ftrace_function will return -EINVAL on > builds !WITH_REGS: > > https://git.kernel.org/pub/scm/linux/kernel/git/mhiramat/linux.git/tree/kernel/trace/ftrace.c?h=topic/fprobe-ftrace-regs&id=2ca022b2753ae0d2a2513c95f7ed5b5b727fb2c4#n338 > > As documented here: > > https://git.kernel.org/pub/scm/linux/kernel/git/mhiramat/linux.git/tree/include/linux/ftrace.h?h=topic/fprobe-ftrace-regs&id=2ca022b2753ae0d2a2513c95f7ed5b5b727fb2c4#n188 > > There are two parts to using sparse pt_regs. One is "static": having > WITH_ARGS in the config, the second one is "dynamic": a ftrace ops > needs to specify that it doesn't want to go through the ftrace > trampoline that saves a full pt_regs, by not giving > FTRACE_OPS_FL_SAVE_REGS. If we want fprobe to work on builds > !WITH_REGS then we should both remove Kconfig dependencies to > WITH_REGS (like you've done) but also stop passing this ftrace ops > flag. Said in a different way: there are arches that support both WITH_ARGS and WITH_REGS (like x86 actually). They have two ftrace trampolines compiled in: ftrace_caller and ftrace_regs_caller, one for each usecase. If you register to ftrace with the FTRACE_OPS_FL_SAVE_REGS flag you are telling it that what you want is a pt_regs. If you are trying to move away from pt_regs and support ftrace_regs in the more general case (meaning, in the case where it can contain a sparse pt_regs) then you should stop passing that flag so you go through the lighter, faster trampoline and test your code in the circumstances where ftrace_regs isn't just a regular pt_regs but an actually sparse or light data structure. I hope that makes my thoughts clearer? It's a hairy topic ahah
