Re: [PATCH bpf-next v4 2/2] selftests/bpf: Verify rejection of sleepable tracing prog
[email protected] Wed, 05 Aug 2026 15:32:23 +0000
| Newsgroups | org.kernel.vger.bpf |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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/[email protected]?part=2