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. > > > > > static int > > > kprobe_multi_link_handler(struct fprobe *fp, unsigned long fentry_ip, > > > - unsigned long ret_ip, struct pt_regs *regs, > > > + unsigned long ret_ip, struct ftrace_regs *fregs, > > > void *data) > > > { > > > struct bpf_kprobe_multi_link *link; > > > + struct pt_regs *regs = ftrace_get_regs(fregs); > > > + > > > + if (!regs) > > > + return 0; > > > > (with the above comment addressed) this means that BPF multi_kprobe > > would successfully attach on builds WITH_ARGS but the programs would > > never actually run because here regs would be 0. This is a confusing > > failure mode for the user. I think that if multi_kprobe won't work > > (because we don't have a pt_regs conversion path yet), the user should > > be notified at attachment time that they won't be getting any events. > > Yes, so I changed it will not be compiled in that case. Ah ok I missed the CONFIG_DYNAMIC_FTRACE_WITH_REGS guard that you keep between patch 1 and 6 to avoid this case. (after patch 6, it's no longer an issue) then that's fine.
