BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Yonghong Song" <yonghong.song@linux.dev>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v3 19/20] selftests/bpf: Cover the exception cleanup shapes the chain does not reach
Date: Sun, 20 Sep 2026 06:01:17 +0000	[thread overview]
Message-ID: <20260920060117.B1F911F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260920054403.874319-1-yonghong.song@linux.dev>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] bpf: multi-line comments violate the modern BPF subsystem style
--

commit 31d63d33bfdfb4e044e29aa2e2717a6f909808c9
Author: Yonghong Song <yonghong.song@linux.dev>

selftests/bpf: Cover the exception cleanup shapes the chain does not reach

This commit adds tests to cover exception cleanup scenarios that the call
chain doesn't reach. It introduces new shapes like dead continuations, shared
callees, and throwing subprograms in BPF selftests.

> diff --git a/tools/testing/selftests/bpf/prog_tests/exceptions_cleanup.c b/tools/testing/selftests/bpf/prog_tests/exceptions_cleanup.c
> --- a/tools/testing/selftests/bpf/prog_tests/exceptions_cleanup.c
> +++ b/tools/testing/selftests/bpf/prog_tests/exceptions_cleanup.c
[ ... ]
> +	/* A pad in the main program's own frame, not in a subprogram. */
> +	if (test__start_subtest("main_program_pad"))
> +		run_shape(skel, skel->progs.entry_main_pad, 101, THROW_COOKIE,
> +			  RAN_MAIN_PAD);
> +
> +	/* The same call site either way: the subprogram's throw unwinds into
> +	 * this frame and runs its pad, an extension's stops at its own boundary.
> +	 */

[Severity: Low]
This isn't a bug, but does this comment in test_shapes() violate the modern
BPF subsystem multi-line comment style? The opening /* is preferred to be
on its own line.

> +	if (test__start_subtest("freplace_subprog_throws"))
> +		run_shape(skel, skel->progs.entry_freplace, 7, THROW_COOKIE,
> +			  RAN_FREPLACE);
> +	if (test__start_subtest("freplace_extension_throws"))
> +		test_freplace(skel);
[ ... ]
> diff --git a/tools/testing/selftests/bpf/progs/exceptions_cleanup_shapes.c b/tools/testing/selftests/bpf/progs/exceptions_cleanup_shapes.c
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/exceptions_cleanup_shapes.c
[ ... ]
> +__u64 magic = 0x5eed;
> +__u64 pads_ran = 0;
> +__u64 pad_runs = 0;
> +
> +/* 1. Everything a cleanup table leaves dead: a throw's continuation, the tail
> + * after a resume with an ld_imm64 and a branch in it, and the block only that
> + * continuation reaches.
> + */

[Severity: Low]
This isn't a bug, but does this multi-line comment above sweep_frame() follow
the preferred BPF subsystem format? The opening /* should typically reside
on its own line.

> +static __used __naked __noinline __u64 sweep_frame(void)
> +{
[ ... ]
> +SEC("syscall")
> +int entry_sweep(void *ctx)
> +{
> +	return sweep_frame();
> +}
> +
> +/* 2. A callee called from both a covered and an uncovered site: the pad
> + * belongs to the call site, not the callee. Either site can throw, and the RCU
> + * lock between them is what an unwind out of the uncovered one leaks.
> + */

[Severity: Low]
This isn't a bug, but similarly, does this comment above shared_callee() need
the opening /* placed on its own line to match the modern BPF comment style?

> +static __used __noinline __u64 shared_callee(__u64 x)
> +{
> +	if (x > 100)

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

  reply	other threads:[~2026-09-20  6:01 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-20  5:42 [PATCH bpf-next v3 00/20] bpf: Run exception cleanup landing pads when bpf_throw() unwinds Yonghong Song
2026-09-20  5:42 ` [PATCH bpf-next v3 01/20] bpf: Accept the compiler's exception cleanup table at program load Yonghong Song
2026-09-20  5:56   ` sashiko-bot
2026-09-21 15:43     ` Yonghong Song
2026-09-20  6:32   ` bot+bpf-ci
2026-09-21 15:28     ` Yonghong Song
2026-09-20  5:42 ` [PATCH bpf-next v3 02/20] bpf: Add the bpf_unwind_resume() kfunc Yonghong Song
2026-09-20  5:42 ` [PATCH bpf-next v3 03/20] bpf: Add lookups for exception cleanup resumes and landing pads Yonghong Song
2026-09-20  6:31   ` bot+bpf-ci
2026-09-21 14:06     ` Yonghong Song
2026-09-20  5:42 ` [PATCH bpf-next v3 04/20] bpf: Prepare for an exception cleanup table before the CFG walk Yonghong Song
2026-09-20  5:42 ` [PATCH bpf-next v3 05/20] bpf: Make exception landing pads reachable in the CFG Yonghong Song
2026-09-20  5:42 ` [PATCH bpf-next v3 06/20] bpf: Explore the landing pads no call site reaches Yonghong Song
2026-09-20  5:43 ` [PATCH bpf-next v3 07/20] bpf: Refuse exception cleanup shapes bpf_throw() cannot dispatch Yonghong Song
2026-09-20  6:32   ` bot+bpf-ci
2026-09-21 14:08     ` Yonghong Song
2026-09-20  5:43 ` [PATCH bpf-next v3 08/20] bpf: Walk the exception unwind in the verifier Yonghong Song
2026-09-20  5:43 ` [PATCH bpf-next v3 09/20] bpf: Refuse a private stack for a program with an exception cleanup table Yonghong Song
2026-09-20  5:43 ` [PATCH bpf-next v3 10/20] bpf: Dispatch exception cleanup pads from bpf_throw() Yonghong Song
2026-09-20  6:32   ` bot+bpf-ci
2026-09-21 15:55     ` Yonghong Song
2026-09-20  5:43 ` [PATCH bpf-next v3 11/20] bpf, x86: Dispatch exception cleanup pads at run time Yonghong Song
2026-09-20  5:43 ` [PATCH bpf-next v3 12/20] bpf, arm64: " Yonghong Song
2026-09-20  5:43 ` [PATCH bpf-next v3 13/20] libbpf: Resolve the compiler's _Unwind_Resume to the kernel's kfunc Yonghong Song
2026-09-20  5:43 ` [PATCH bpf-next v3 14/20] libbpf: Add cleanup_info to bpf_prog_load_opts Yonghong Song
2026-09-20  6:31   ` bot+bpf-ci
2026-09-21 15:00     ` Yonghong Song
2026-09-20  5:43 ` [PATCH bpf-next v3 15/20] libbpf: Collect .bpf_cleanup records and pass them to the kernel Yonghong Song
2026-09-20  5:43 ` [PATCH bpf-next v3 16/20] libbpf: Carry the exception cleanup table through the light skeleton Yonghong Song
2026-09-20  6:01   ` sashiko-bot
2026-09-21 14:14     ` Yonghong Song
2026-09-20  5:43 ` [PATCH bpf-next v3 17/20] libbpf: Let the static linker carry .bpf_cleanup relocations Yonghong Song
2026-09-20  6:00   ` sashiko-bot
2026-09-21 14:20     ` Yonghong Song
2026-09-20  6:31   ` bot+bpf-ci
2026-09-21 14:21     ` Yonghong Song
2026-09-20  5:43 ` [PATCH bpf-next v3 18/20] selftests/bpf: Add an end-to-end .bpf_cleanup exception test Yonghong Song
2026-09-20  5:59   ` sashiko-bot
2026-09-20  5:44 ` [PATCH bpf-next v3 19/20] selftests/bpf: Cover the exception cleanup shapes the chain does not reach Yonghong Song
2026-09-20  6:01   ` sashiko-bot [this message]
2026-09-20  6:46   ` bot+bpf-ci
2026-09-21 14:27     ` Yonghong Song
2026-09-20  5:44 ` [PATCH bpf-next v3 20/20] selftests/bpf: Load an exception cleanup program from a light skeleton Yonghong Song
2026-09-20  6:31   ` bot+bpf-ci
2026-09-21 14:30     ` Yonghong Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260920060117.B1F911F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox