On Wed, Aug 2, 2023 at 1:12 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > On Wed, 2 Aug 2023 12:48:14 -0700 > Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > > On Wed, Aug 2, 2023 at 11:38 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > > > > > On Wed, 2 Aug 2023 11:24:12 -0700 > > > Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > > > > > > This is a non starter. > > > > bpf progs expect arch dependent 'struct pt_regs *' and we cannot change that. > > > > > > If the progs are compiled into native code, isn't there optimizations that > > > could be done? That is, if ftrace_regs is available, and the bpf program is > > > just using the subset of pt_regs, is it possible that it could be compiled > > > to use ftrace_regs? > > > > > > Forgive my ignorance on how BPF programs turn into executables when running > > > in the kernel. > > > > Right. It's possible for the verifier to do an offset rewrite, > > forbid certain access, always return 0 on load from certain offset, > > and so on. > > It's all non trivial amount of work. > > ftrace_partial_regs() from ftrace_regs into pt_regs is so much simpler. > > Sure, and the copy could be the solution we have in the near future, but if > we could optimize it in the future, then perhaps it would be worth doing it. > > Also, how are the bpf programs referencing the pt_regs? Typically through macros that abstract arch differences away in tools/lib/bpf/bpf_tracing.h PT_REGS_PARM1 PT_REGS_PARM1_CORE PT_REGS_PARM1_SYSCALL pt_regs at syscall entry is special, since syscall calling convention is different from the rest of the kernel. ftrace_regs cannot help with that either. > Could a ftrace_regs > API be added too? Potentially yes, but I don't see the value. bpf users are slowly migrating to fentry/fexit that has accurate args and return value and much faster. kprobes are still heavily used, of course. multi-kprobe (with fprobe_ips underneath) is a new addition that is also very important to some users. > If the verifier sees that the program is using > ftrace_regs, it could then use the lighter weight fprobes for access, > otherwise it falls back to the kprobe version. > > -- Steve