Re: [PATCH bpf-next v4 18/25] selftests/bpf: Add tests for BPF function stack arguments

[Yonghong Song <yonghong.song@linux.dev>]

On 5/15/26 8:16 AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The test `test_async_cb_many` uses a hardcoded `usleep(50)` to wait for an asynchronous BPF timer to execute, which is prone to race conditions and flakiness on loaded CI systems.
> --
>
> commit 12812727f17076398fed8cfc802771db232582f8
> Author: Yonghong Song <yonghong.song@linux.dev>
>
> selftests/bpf: Add tests for BPF function stack arguments
>
> This commit adds selftests for stack argument passing in BPF-to-BPF subprog
> and kfunc calls with more than 5 arguments. It covers scalar, pointer, mixed,
> dynptr, memory buffer, iterator, const string, and timer pointers.
>
>> diff --git a/tools/testing/selftests/bpf/prog_tests/stack_arg.c b/tools/testing/selftests/bpf/prog_tests/stack_arg.c
>> new file mode 100644
>> index 0000000000000..d61bac33f8092
>> --- /dev/null
>> +++ b/tools/testing/selftests/bpf/prog_tests/stack_arg.c
> [ ... ]
>> +static void test_async_cb_many(void)
>> +{
> [ ... ]
>> +	run_subtest(skel->progs.test_async_cb_many_args, 0);
>> +
>> +	/* Wait for the timer callback to fire and verify the result.
>> +	 * 10+20+30+40+50+60+70+80 = 360
>> +	 */
>> +	usleep(50);
> Could this short sleep lead to flaky test failures on loaded CI systems?
>
> Timer callbacks are executed in softirq context, and under load, scheduling
> delays could easily exceed 50 microseconds. This might cause the test process
> to wake up and read timer_result before the callback has actually executed.
>
> Would a polling loop with a reasonable timeout be more reliable here?

The prog_tests/tiemr.c uses 'usleep(50);' which seems working fine.
So I used it too.

>
>> +	ASSERT_EQ(skel->bss->timer_result, 360, "timer_result");
>> +
>> +out:
>> +	stack_arg__destroy(skel);
>> +}