Messages in this thread | | | From | Alexei Starovoitov <> | Date | Tue, 1 Aug 2023 15:18:56 -0700 | Subject | Re: [PATCH v4 3/9] bpf/btf: Add a function to search a member of a struct/union |
| |
On Tue, Aug 1, 2023 at 8:32 AM Steven Rostedt <rostedt@goodmis.org> wrote: > > On Tue, 1 Aug 2023 11:20:36 -0400 > Steven Rostedt <rostedt@goodmis.org> wrote: > > > The solution was to come up with ftrace_regs, which just means it has all > > the registers to extract the arguments of a function and nothing more. Most > > This isn't 100% true. The ftrace_regs may hold a fully filled pt_regs. As > the FTRACE_WITH_REGS callbacks still get passed a ftrace_regs pointer. They > will do: > > void callback(..., struct ftrace_regs *fregs) { > struct pt_regs *regs = ftrace_get_regs(fregs); > > > Where ftrace_get_regs() will return the pt_regs only if it is fully filled. > If it is not, then it returns NULL. This was what the x86 maintainers > agreed with.
arch/arm64/include/asm/ftrace.h:#define arch_ftrace_get_regs(regs) NULL
Ouch. That's very bad. We care a lot about bpf running well on arm64.
If you guys decide to convert fprobe to ftrace_regs please make it depend on kconfig or something. bpf side needs full pt_regs. It's not about access to args. pt_regs is passed from bpf prog further into all kinds of perf event functions including stack walking. I think ORC unwinder might depend on availability of all registers. Other perf helpers might need it too. Like perf_event_output. bpf progs need to access arguments, no doubt about that. If ftrace_regs have them exactly in the same offsets as in pt_regs that might work transparently for bpf progs, but, I'm afraid, it's not the case on all archs. So we need full pt_regs to make sure all paths are still working.
Adding Jiri and others.
| |