On Thu, May 14, 2026 at 02:55:27PM +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 82b3c0ce9253..d553485e7db5 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 be34c4087ff5..606601ccdc42 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); > > +} > > + > > #endif > > Is this test reliable across different compiler versions and optimizations? > > The 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 > 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. > > 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?
answered by Andrii in: https://lore.kernel.org/bpf/caef4bzz-naspof+-vlyz1d8ewrvd5jwauhrwx8xznrx7zpy...@mail.gmail.com/ jirka
