On Wed, 2 Aug 2023 09:21:46 +0900 Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx> wrote: > > Then use kprobes. When I asked Masami what the difference between fprobes > > and kprobes was, he told me that it would be that it would no longer rely > > on the slower FTRACE_WITH_REGS. But currently, it still does. > > kprobes needs to keep using pt_regs because software-breakpoint exception > handler gets that. And fprobe is used for bpf multi-kprobe interface, > but I think it can be optional. > > So until user-land tool supports the ftrace_regs, you can just disable > using fprobes if CONFIG_DYNAMIC_FTRACE_WITH_REGS=n I'm confused. I asked about the difference between kprobes on ftrace and fprobes, and you said it was to get rid of the requirement of FTRACE_WITH_REGS. https://lore.kernel.org/all/20230120205535.98998636329ca4d5f8325bc3@xxxxxxxxxx/ > > Then you can safely use > > struct pt_regs *regs = ftrace_get_regs(fregs); > > I think we can just replace the CONFIG_FPROBE ifdefs with > CONFIG_DYNAMIC_FTRACE_WITH_REGS in kernel/trace/bpf_trace.c > And that will be the first version of using ftrace_regs in fprobe. But it is still slow. The FTRACE_WITH_REGS gives us the full pt_regs and saves all registers including flags, which is a very slow operation (and noticeable in profilers). And this still doesn't work on arm64. Maybe we can add a ftrace_partial_regs(fregs) that returns a partially filled pt_regs, and the caller that uses this obviously knows its partial (as it's in the name). But this doesn't quite help out arm64 because unlike x86, struct ftrace_regs does not contain an address compatibility with pt_regs fields. It would need to do a copy. ftrace_partial_regs(fregs, ®s) ? -- Steve
