Re: [PATCH 1/2] arm64: ftrace: enable single ftrace_ops for direct calls

[Jiri Olsa <olsajiri@gmail.com>]

On Fri, Jul 31, 2026 at 10:30:37AM +0800, Leon Hwang wrote:
> On 30/7/26 18:58, Jiri Olsa wrote:
> > 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?
> > 
> 
> Right.
> 
> Pls see the sibling thread with Ihor. With in-range BPF trampoline
> allocation, the slow-path regression should mostly disappear.
> 
> Let's continue the discussion in that thread.

please paste the link/subject for that thread

thanks,
jirka