On Thu, May 21, 2026 at 01:26:07PM +0000, [email protected] wrote: > > diff --git a/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c > > b/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c > > index 969f4deba9fd..efff0c515184 100644 > > --- a/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c > > +++ b/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c > > [ ... ] > > > diff --git a/tools/testing/selftests/bpf/prog_tests/usdt.c > > b/tools/testing/selftests/bpf/prog_tests/usdt.c > > index fda3a298ccfc..8004c9568ffa 100644 > > --- a/tools/testing/selftests/bpf/prog_tests/usdt.c > > +++ b/tools/testing/selftests/bpf/prog_tests/usdt.c > > [ ... ] > > > diff --git a/tools/testing/selftests/bpf/progs/test_usdt.c > > b/tools/testing/selftests/bpf/progs/test_usdt.c > > index f00cb52874e0..0ee78fb050a1 100644 > > --- a/tools/testing/selftests/bpf/progs/test_usdt.c > > +++ b/tools/testing/selftests/bpf/progs/test_usdt.c > > [ ... ] > > > diff --git a/tools/testing/selftests/bpf/usdt_2.c > > b/tools/testing/selftests/bpf/usdt_2.c > > index b359b389f6c0..5e38f8605b02 100644 > > --- a/tools/testing/selftests/bpf/usdt_2.c > > +++ b/tools/testing/selftests/bpf/usdt_2.c > > @@ -13,4 +13,17 @@ void usdt_2(void) > > USDT(optimized_attach, usdt_2); > > } > > > > +static volatile unsigned long usdt_red_zone_arg1 = 0xDEADBEEF; > > +static volatile unsigned long usdt_red_zone_arg2 = 0xCAFEBABE; > > +static volatile unsigned long usdt_red_zone_arg3 = 0xFEEDFACE; > > + > > +void __attribute__((noinline)) usdt_red_zone_trigger(void) > > +{ > > + unsigned long a1 = usdt_red_zone_arg1; > > + unsigned long a2 = usdt_red_zone_arg2; > > + unsigned long a3 = usdt_red_zone_arg3; > > + > > + USDT(optimized_attach, usdt_red_zone, a1, a2, a3); > > +} > > Following up on a review comment from sashiko-bot: is this test reliable > across different compiler versions?
Andrii replied this one in the original post: https://lore.kernel.org/bpf/caef4bzz-naspof+-vlyz1d8ewrvd5jwauhrwx8xznrx7zpy...@mail.gmail.com/ jirka > > The x86-64 USDT macro uses the "nor" inline assembly constraint, which allows > the compiler to allocate these operands to CPU registers. Because there is no > register pressure in usdt_red_zone_trigger(), modern compilers might allocate > the local variables a1, a2, and a3 directly to registers rather than the > stack's red zone. > > If the operands are placed in registers, the uprobe CALL optimization > clobbering [rsp-8] will not corrupt them. This could cause the test to pass > even on buggy kernels, creating a false positive. > > The author acknowledged this concern but kept the test as-is, noting that > selftests compile with -O0 and there's also an assembly-based test. > > Would it be safer to explicitly force these operands into the red zone using > inline assembly constraints, rather than depending on the compiler's register > allocator? > > Reference: > 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/26227520868
