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? Could a ftrace_regs API be added too? 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
