Re: [PATCH bpf-next v3 07/20] bpf: Refuse exception cleanup shapes bpf_throw() cannot dispatch

[Yonghong Song <yonghong.song@linux.dev>]

On 9/19/26 11:32 PM, bot+bpf-ci@kernel.org wrote:
>> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
>> index 0cd7c27a50fa..382177b80745 100644
>> --- a/include/linux/bpf_verifier.h
>> +++ b/include/linux/bpf_verifier.h
>> @@ -683,6 +683,7 @@ struct bpf_insn_aux_data {
>>   	bool is_iter_next; /* bpf_iter_<type>_next() kfunc call */
>>   	bool cleanup_throw_site; /* call to bpf_throw() */
>>   	bool cleanup_resume_site; /* call to bpf_unwind_resume() */
>> +	bool in_cleanup_pad; /* only runs with an exception in flight */
>>   	/*
>>   	 * 1 + the instruction index of the exception cleanup landing pad this
>>   	 * call site unwinds to, or 0 for none.
> Does the in_cleanup_pad comment accurately describe what the field
> represents at this commit? The comment says "only runs with an exception
> in flight", but cleanup_mark_pad_bodies() marks reachability from a
> landing pad without checking whether the pad is unreachable by ordinary
> control flow.
>
> For example, with a record {begin_off=0, end_off=1, landing_pad_off=1}:
>
>      0: call pcall foo        /* covered by the record */
>      1: r0 = 0                /* landing pad, also insn 0's fall-through */
>      2: call bpf_unwind_resume
>      3: exit
>
> check_cleanup_info() permits this (it only rejects a pad that lies
> *inside* a call-site range). cleanup_reachability() gives pad 1 only
> CLEANUP_REACH_RESUME, cleanup_pad_is_catch() accepts it, and insns 1-2
> get in_cleanup_pad = true. Yet on normal return from foo, execution falls
> into insns 1-2 with no exception in flight.
>
> The next commit (c046fa312ea4 "bpf: Walk the exception unwind in the
> verifier") adds the state->unwinding check that actually refuses this
> shape ("bpf_unwind_resume() at insn %d reached without an exception in
> flight"). Should the field comment say "reachable from a landing pad"
> rather than "only runs with an exception in flight" until that enforcement
> is in place, or does the check belong in this commit since the changelog
> promises to refuse every cleanup shape bpf_throw() cannot dispatch?

You are right. The comment is not good. Let us do:
   bool in_cleanup_pad; /* reachable from an exception cleanup landing pad */

>
>> diff --git a/kernel/bpf/exception.c b/kernel/bpf/exception.c
>> index cc7c8595dd64..4859d6484cc8 100644
>> --- a/kernel/bpf/exception.c
>> +++ b/kernel/bpf/exception.c
> [ ... ]
>
>> @@ -37,6 +162,255 @@ static void cleanup_mark_kfunc_sites(struct bpf_verifier_env *env)
> [ ... ]
>
>> +/* What every instruction can reach along intra-subprog edges, for
>> + * cleanup_pad_is_catch(). One backward walk over a predecessor index, rather
>> + * than a forward walk from each landing pad, which would be quadratic.
>> + */
>> +static int cleanup_reachability(struct cleanup_ctx *ctx)
>> +{
>> +	struct bpf_verifier_env *env = ctx->env;
>> +	u32 len = env->prog->len;
>> +	struct cleanup_cursor c = CLEANUP_CURSOR_INIT;
>> +	u32 *head = NULL, *link = NULL;
>> +	bool *queued = NULL;
>> +	u32 i, sp = 0;
>> +	void *scratch;
>> +	const struct cleanup_alloc_req tab[] = {
>> +		{ (void **)&head,   len,             sizeof(*head) },
>> +		{ (void **)&link,   2 * (size_t)len, sizeof(*link) },
>> +		{ (void **)&queued, len,             sizeof(*queued) },
>> +	};
>> +
>> +	scratch = cleanup_alloc(tab, ARRAY_SIZE(tab));
>> +	if (!scratch)
>> +		return -ENOMEM;
>> +
>> +	/* Index the predecessors, and seed the walk at the terminators. */
>> +	for (i = 0; i < len; i++) {
> [ ... ]
>
>> +	}
>> +
>> +	/* Each instruction re-enters the worklist at most once per bit it
>> +	 * gains, so this is linear in the number of edges.
>> +	 */
>> +	while (sp) {
> This isn't a bug, but could the two multi-line comments in
> cleanup_reachability() follow the BPF comment style with the opening /*
> on its own line? The other multi-line comments added by this series use
> that format, and the guide requires it for files under kernel/bpf/.
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/35492765538