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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The test deliberately triggers a kernel BUG on a failing run by executing an active kernel-crashing payload when the tested bug is present, disrupting automated CI environments.
--

--- Patch [2]: [PATCH bpf-next v4 2/2] selftests/bpf: Verify rejection of sleepable tracing prog ---
commit b744623263d5a19a3bd8be3aa0ccd3a94a64c24e
Author: Leon Hwang <leon.hwang@linux.dev>

selftests/bpf: Verify rejection of sleepable tracing prog

This commit adds a selftest to verify that a sleepable tracing program cannot
attach to a '__x64_sys' prefix prog target. It ensures the kernel properly
rejects this to avoid sleeping function bugs in invalid contexts.

> diff --git a/tools/testing/selftests/bpf/prog_tests/fexit_bpf2bpf.c b/tools/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);
>  }
>  
> +static void test_sleepable_fentry_to_xdp(void)
> +{
[ ... ]
> +	err = bpf_program__set_attach_target(skel->progs.fentry_xdp, prog_fd, "__x64_sys_nop");
> +	if (!ASSERT_OK(err, "bpf_program__set_attach_target"))
> +		goto out;
> +
> +	err = fentry_sleepable__load(skel);
> +	ASSERT_ERR(err, "fentry_sleepable__load");
> +	if (err)
> +		goto out;
> +
> +	skel->links.fentry_xdp = bpf_program__attach_trace(skel->progs.fentry_xdp);

[Severity: Medium]
Will this execution path crash automated CI environments when running on a
kernel without the fix?

If fentry_sleepable__load() unexpectedly succeeds and returns 0, ASSERT_ERR()
will log the test failure, but the subsequent 'if (err)' check evaluates to
false. This causes the test to fall through to the attach and ping payload
rather than jumping to 'out'.

Since executing this payload triggers a kernel panic when the bug is present,
should this error check jump to 'out' when err == 0 to fail gracefully?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260805150810.34907-1-leon.hwang@linux.dev?part=2