On 29/7/26 19:56, Jiri Olsa wrote: > On Mon, Jul 27, 2026 at 10:28:43PM +0800, Leon Hwang wrote: >> The BPF tracing multi link updates several direct-call sites through one >> ftrace_ops. Its implementation is therefore gated by >> HAVE_SINGLE_FTRACE_DIRECT_OPS in addition to >> DYNAMIC_FTRACE_WITH_DIRECT_CALLS. >> >> Select HAVE_SINGLE_FTRACE_DIRECT_OPS whenever arm64 enables dynamic ftrace >> direct calls. This enables BPF tracing multi links on arm64. Also >> generalize the unreachable-trampoline comment because the single-ops path >> does not use ops->direct_call. > > hi, > iirc arm needs ops->direct_call for trampolines to work properly, > that's the reason we enabled single ftrace_ops on x86 only: > > 424f6a361096 bpf,x86: Use single ftrace_ops for direct calls > > I don't understand the arm usage of op->direct_call, but it looks like > (codex thinks) that the fast path won't always work without op->direct_call > being set
In theory, op->direct_call is the fallback for the case: HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS=y, out-of-range target, and non-BPF direct ops. This is what Codex thinks about. However, after searching the call sites of register_ftrace_direct()/__modify_ftrace_direct() in kernel, which would set ops->direct_call, the actual callers are in bpf/trampoline.c, which have been gated with HAVE_SINGLE_FTRACE_DIRECT_OPS. That said, for normal usage of HAVE_SINGLE_FTRACE_DIRECT_OPS=y, op->direct_call is unused. If someone uses register_ftrace_direct() or modify_ftrace_direct/_nolock() outside BPF in the future, op->direct_call will be used. So, I'd like to drop the comment change in the next revision. Thanks, Leon > > from arch/arm64/kernel/entry-ftrace.S: > > #ifdef CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS > /* > * If the op has a direct call, handle it immediately without > * saving/restoring registers. > */ > ldr x17, [x11, #FTRACE_OPS_DIRECT_CALL] // > op->direct_call > cbnz x17, ftrace_caller_direct > #endif > #endif > > jirka
