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

[Leon Hwang <leon.hwang@linux.dev>]

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.

Thanks,
Leon