> diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c
> b/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c
> index 35adc3f6d443..5a864cd8ad1b 100644
> --- a/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c
> +++ b/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c
> @@ -252,10 +252,17 @@ static void kprobe_multi_attach_api_subtest(void)
> kprobe_multi__destroy(skel);
> }
>
> -/* defined in prog_tests/uprobe_multi_test.c */
> -void uprobe_multi_func_1(void);
> -void uprobe_multi_func_2(void);
> -void uprobe_multi_func_3(void);
> +/*
> + * Weak uprobe target stubs. noinline is required because
> + * uprobe_multi_test_run() takes their addresses to configure the BPF
> + * program's attachment points; an inlined function has no stable
> + * address in the binary to probe. The strong definitions in
> + * uprobe_multi_test.c take precedence when that translation unit is
> + * linked.
> + */
> +noinline __weak void uprobe_multi_func_1(void) {}
> +noinline __weak void uprobe_multi_func_2(void) {}
> +noinline __weak void uprobe_multi_func_3(void) {}
Can compiler optimization passes like Identical Code Folding (ICF) merge
these three structurally identical weak stub functions into a single
memory address?
If they are folded into a single address, bpf_program__attach_uprobe_multi()
would attach three separate uprobes to the exact same offset, each with a
different cookie. Calling any of the functions would then execute the shared
address, triggering all three uprobes simultaneously:
uprobe_multi_test_run() {
uprobe_multi_func_1(); // triggers all 3 uprobes
uprobe_multi_func_2(); // triggers all 3 uprobes
uprobe_multi_func_3(); // triggers all 3 uprobes
}
This would increment the BPF program counters multiple times per call,
causing assertions like:
ASSERT_EQ(skel->bss->uprobe_multi_func_1_result, 1, ...);
to fail deterministically, as the result would be 3 instead of 1.
Would it make sense to make these stubs structurally unique, perhaps by
adding unique inline assembly to each?
This concern was raised by [email protected] in v9:
https://lore.kernel.org/bpf/[email protected]/
[ ... ]
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/25167006036
