Re: [PATCH bpf-next v3 2/2] selftests/bpf: Verify rejection of sleepable tracing prog

Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:
- [Medium] The test contains dead reproducer code that intentionally crashe=
s the kernel on test failure instead of failing gracefully.
--

--- Patch [2]: [PATCH bpf-next v3 2/2] selftests/bpf: Verify rejection of s=
leepable tracing prog ---
commit 22c464db2aa39d78b7ca52b202c4a7828b6fddc2
Author: Leon Hwang <[email protected]>

selftests/bpf: Verify rejection of sleepable tracing prog

This commit adds a test to verify that a sleepable tracing program cannot
attach to a '__x64_sys' prefixed program target.

> diff --git a/tools/testing/selftests/bpf/prog_tests/fexit_bpf2bpf.c b/too=
ls/testing/selftests/bpf/prog_tests/fexit_bpf2bpf.c
> index 4a87d7163c8c7..2523c07a16c65 100644
> --- a/tools/testing/selftests/bpf/prog_tests/fexit_bpf2bpf.c
> +++ b/tools/testing/selftests/bpf/prog_tests/fexit_bpf2bpf.c
[ ... ]
> @@ -576,6 +577,60 @@ static void test_func_replace_progmap(void)
>  	freplace_progmap__destroy(skel);
>  }
> =20
> +static void test_sleepable_fentry_to_xdp(void)
> +{
[ ... ]
> +	err =3D fentry_sleepable__load(skel);
> +	ASSERT_ERR(err, "fentry_sleepable__load");
> +	if (err)
> +		goto out;
> +
> +	skel->links.fentry_xdp =3D bpf_program__attach_trace(skel->progs.fentry=
_xdp);
> +	if (!ASSERT_OK_PTR(skel->links.fentry_xdp, "bpf_program__attach_trace"))
> +		goto out;
> +
> +	skel_xdp->links.__x64_sys_nop =3D bpf_program__attach_xdp(skel_xdp->pro=
gs.__x64_sys_nop,
> +								ifindex);
> +	if (!ASSERT_OK_PTR(skel_xdp->links.__x64_sys_nop, "bpf_program__attach_=
xdp"))
> +		goto out;
> +
> +	err =3D system("ping -q -c 1 -W 1 127.0.0.1 > /dev/null");
> +	ASSERT_OK(err, "ping");
> +	ASSERT_ERR(skel->bss->retval, "retval");

[Severity: Medium]
Will this sequence crash the kernel if the test fails?

If the kernel lacks the fix, fentry_sleepable__load() will return 0.
ASSERT_ERR() will correctly log a test failure, but since err =3D=3D 0, the
if (err) goto out; check will be bypassed.

The test will then proceed to attach the sleepable program and trigger it
with ping, intentionally causing the kernel panic described in the commit
message.

Additionally, when the kernel is fixed and the test passes, this entire blo=
ck
is dead code because fentry_sleepable__load() returns < 0 and the test exits
early via goto out.

Could this test fail gracefully without crashing the system during automated
bisections?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260804145710.4306=
[email protected]?part=3D2