Re: [PATCHv4 12/13] selftests/bpf: Add tests for uprobe nop10 red zone clobbering

[Jiri Olsa <olsajiri@gmail.com>]

On Tue, May 26, 2026 at 09:46:42PM +0000, bot+bpf-ci@kernel.org 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
> 
> [ ... ]
> 
> > @@ -855,6 +897,37 @@ static void test_uprobe_race(void)
> >  #define __NR_uprobe 336
> >  #endif
> >
> > +static void test_uprobe_red_zone(void)
> > +{
> > +	struct uprobe_syscall_executed *skel;
> > +	struct bpf_link *link;
> > +	void *nop10_addr;
> > +	size_t offset;
> > +	int i;
> > +
> > +	nop10_addr = find_nop10(uprobe_red_zone_test);
> > +	if (!ASSERT_NEQ(nop10_addr, NULL, "find_nop10"))
> > +		return;
> > +
> > +	skel = uprobe_syscall_executed__open_and_load();
> > +	if (!ASSERT_OK_PTR(skel, "open_and_load"))
> > +		return;
> > +
> > +	offset = get_uprobe_offset(nop10_addr);
> > +	link = bpf_program__attach_uprobe_opts(skel->progs.test_uprobe,
> > +			0, "/proc/self/exe", offset, NULL);
> > +	if (!ASSERT_OK_PTR(link, "attach_uprobe"))
> > +		goto cleanup;
> > +
> > +	for (i = 0; i < 10; i++)
> > +		ASSERT_EQ(uprobe_red_zone_test(), 0, "red_zone_intact");
> 
> Does this loop execute too quickly to guarantee the uprobe optimization has
> completed?
> 
> Uprobe optimization is performed asynchronously by a worker thread. Since this
> is a tight loop with no delays or blocking, the 10 iterations might finish
> before the background worker patches the code.

uprobe is optimized synchronously whithin its first hit

> 
> If all hits execute on the unoptimized INT3 path, the test could falsely pass
> on kernels where the CALL-based optimization bug is present.
> 
> (This concern was raised by sashiko-bot@kernel.org in v1 and remains
> unaddressed:
> https://lore.kernel.org/bpf/20260514212219.BF1F3C2BCB3@smtp.kernel.org/)
> 
> > +
> > +	bpf_link__destroy(link);
> > +
> > +cleanup:
> > +	uprobe_syscall_executed__destroy(skel);
> > +}
> 
> [ ... ]
> 
> > 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);
> > +}
> 
> 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?

I think it's ok the way it is, usdt_red_zone_trigger uses redzone on x86_64 build:

0000000000830d02 <usdt_red_zone_trigger>:
  830d02:       55                      push   %rbp
  830d03:       48 89 e5                mov    %rsp,%rbp
  830d06:       48 8b 05 6b f3 44 03    mov    0x344f36b(%rip),%rax        # 3c80078 <usdt_red_zone_arg1>
  830d0d:       48 89 45 f8             mov    %rax,-0x8(%rbp)
  830d11:       48 8b 05 68 f3 44 03    mov    0x344f368(%rip),%rax        # 3c80080 <usdt_red_zone_arg2>
  830d18:       48 89 45 f0             mov    %rax,-0x10(%rbp)
  830d1c:       48 8b 05 65 f3 44 03    mov    0x344f365(%rip),%rax        # 3c80088 <usdt_red_zone_arg3>
  830d23:       48 89 45 e8             mov    %rax,-0x18(%rbp)

...

jirka