On Tue, Dec 30, 2025 at 6:50 AM Jiri Olsa <[email protected]> wrote: > > At the moment the we allow the jmp attach only for ftrace_ops that > has FTRACE_OPS_FL_JMP set. This conflicts with following changes > where we use single ftrace_ops object for all direct call sites, > so all could be be attached via just call or jmp. > > We already limit the jmp attach support with config option and bit > (LSB) set on the trampoline address. It turns out that's actually > enough to limit the jmp attach for architecture and only for chosen > addresses (with LSB bit set). > > Each user of register_ftrace_direct or modify_ftrace_direct can set > the trampoline bit (LSB) to indicate it has to be attached by jmp. > > The bpf trampoline generation code uses trampoline flags to generate > jmp-attach specific code and ftrace inner code uses the trampoline > bit (LSB) to handle return from jmp attachment, so there's no harm > to remove the FTRACE_OPS_FL_JMP bit. > > The fexit/fmodret performance stays the same (did not drop), > current code: > > fentry : 77.904 ± 0.546M/s > fexit : 62.430 ± 0.554M/s > fmodret : 66.503 ± 0.902M/s > > with this change: > > fentry : 80.472 ± 0.061M/s > fexit : 63.995 ± 0.127M/s > fmodret : 67.362 ± 0.175M/s > > Fixes: 25e4e3565d45 ("ftrace: Introduce FTRACE_OPS_FL_JMP") > Signed-off-by: Jiri Olsa <[email protected]> > --- > include/linux/ftrace.h | 1 - > kernel/bpf/trampoline.c | 32 ++++++++++++++------------------ > kernel/trace/ftrace.c | 14 -------------- > 3 files changed, 14 insertions(+), 33 deletions(-) >
I don't see anything wrong with this from BPF side Acked-by: Andrii Nakryiko <[email protected]> [...]
