Re: [PATCHv6 bpf-next 9/9] bpf,x86: Use single ftrace_ops for direct calls

[Ihor Solodrai]

On 12/30/25 6:50 AM, Jiri Olsa wrote:
> Using single ftrace_ops for direct calls update instead of allocating
> ftrace_ops object for each trampoline.
> 
> With single ftrace_ops object we can use update_ftrace_direct_* api
> that allows multiple ip sites updates on single ftrace_ops object.
> 
> Adding HAVE_SINGLE_FTRACE_DIRECT_OPS config option to be enabled on
> each arch that supports this.
> 
> At the moment we can enable this only on x86 arch, because arm relies
> on ftrace_ops object representing just single trampoline image (stored
> in ftrace_ops::direct_call). Archs that do not support this will continue
> to use *_ftrace_direct api.
> 
> Signed-off-by: Jiri Olsa <jolsa@xxxxxxxxxx>

Hi Jiri,

Me and Kumar stumbled on kernel splats with "ftrace failed to modify",
and if running with KASAN:

  BUG: KASAN: slab-use-after-free in __get_valid_kprobe+0x224/0x2a0

Pasting a full splat example at the bottom.

I was able to create a reproducer with AI, and then used it to bisect
to this patch. You can run it with ./test_progs -t ftrace_direct_race

Below is my (human-generated, haha) summary of AI's analysis of what's
happening. It makes sense to me conceptually, but I don't know enough
details here to call bullshit. Please take a look:

    With CONFIG_HAVE_SINGLE_FTRACE_DIRECT_OPS ftrace_replace_code()
    operates on all call sites in the shared ops. Then if a concurrent
    ftrace user (like kprobe) modifies a call site in between
    ftrace_replace_code's verify pass and its patch pass, then ftrace_bug
    fires and sets ftrace_disabled to 1.

    Once ftrace is disabled, direct_ops_del silently fails to unregister
    the direct call, and the call site still redirects to the stale
    trampoline. After the BPF program is freed, we'll get use-after-free
    on the next trace hit.

The reproducer is not great, because if everything is fine it just hangs.
But with the bug the kernel crashes pretty fast.
Maybe it makes sense to refine it to a proper "stress" selftest?

Reproducer patch: