On Thu, Jul 30, 2026 at 11:05:42AM +0800, Leon Hwang wrote: > 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 any 2nd user on the same function triggers the slow path, and that's fine, the single_ops handles slow path correctly but IIUC the out-of-range target will now always go through slow path, which in current code it doesn't, right? jirka
