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

[sashiko-bot@kernel.org]

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?

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

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260513044949.2382019-1-yonghong.song@linux.dev?part=18