Re: [PATCH 7/7] selftests/bpf: Add tests for uprobe nop10 red zone clobbering

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The `optimized_red_zone` USDT subtest does not guarantee that its arguments are placed in the stack's red zone, rendering it ineffective as a regression test.
- [High] The uprobe regression tests loop too quickly to guarantee that the asynchronous uprobe optimization has completed, making them prone to falsely passing on unfixed kernels.
--

commit c8c0580fb53dfbfe85e78c3bfddc6256a6a88b56
Author: Andrii Nakryiko <andrii@kernel.org>

selftests/bpf: Add tests for uprobe nop10 red zone clobbering

This commit introduces tests to ensure the uprobe nop10 optimization avoids
clobbering the stack's red zone on x86-64. It adds an assembly-level test
that checks for red-zone data integrity and a USDT subtest checking for
correct argument delivery over 10 invocations.

> diff --git a/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c b/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c
> --- 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)
> +{
[ ... ]
> +	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.

If all hits execute on the unoptimized INT3 path, the test could falsely
pass on kernels where the CALL-based optimization bug is present.

> +
> +	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
> --- 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 it guaranteed that the compiler will place these variables in the
red zone? 

On x86_64, the compiler will typically allocate these three arguments
to general-purpose registers rather than spilling them to memory. 

If they are placed in registers or a standard stack frame above rsp, the
uprobe bug wouldn't clobber them, which might allow the test to falsely
pass on an unfixed kernel.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260514135342.22130-1-jolsa@kernel.org?part=7