Re: [PATCH bpf-next v9 08/23] bpf: Refuse a landing pad that does not resume

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

On 10/8/26 10:57 AM, bot+bpf-ci@kernel.org wrote:
>> bpf: Refuse a landing pad that does not resume
> TL;DR: Commit message only: the patch also makes push_callback_call() reject
> callback subprogs that may unwind, even without a cleanup table, but the
> message doesn't mention it. Mention it or split it out?
>
>>      bpf: Refuse a landing pad that does not resume
>>
>>      A cleanup pad runs drop glue and calls bpf_unwind_resume(), so its frame
>>      returns and the unwind goes on. A catch pad carries on in its frame
>>      instead. Only the first is supported: bpf_unwind() rewrites every frame's
>>      return address in one pass, so a catch pad's caller would still resume
>>      at a pad.
>>
>>      Nothing in the record says which kind a pad is, but the code does: a
>>      cleanup pad reaches _Unwind_Resume, a catch pad a return. So the unwind
>>      marks the frame whose pad it enters, and refuses in the marked code:
>>
>>        refused                                  where
>>        ---------------------------------------  ----------------------------
>>        an exit: how a catch pad ends            the pad's own frame
>>        a tail call, a BPF_LD_[ABS|IND]: it      the pad's own frame
>>          leaves through an exit on a failed
>>          load
>>        an indirect jump: nothing a compiler     the pad's own frame
>>          frontend emits in a pad needs one
>>        a bpf_unwind(), a call to a global       the pad and its callees
>>          subprog that might_unwind
>>        a bpf_unwind_resume() outside a pad      any program
>>
>>      The first three are refused only in the pad's own frame: a subprog the
>>      pad calls may do them and still come back.
>>
>>      Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
> The patch also adds a refusal that this table does not list.
> push_callback_call() now calls bpf_exc_check_callback(), which returns
> -EINVAL for any callback subprog with might_unwind set:
>
>    verbose(env, "subprog %d may unwind and is used as a callback\n", subprog);
>
> This check is not about landing pads, and it is not gated on
> env->cleanup_info_cnt.  might_unwind is set for any bpf_unwind() call, so
> it also applies to programs with no cleanup table.  Later in the series,
> bpf_prog_may_unwind() makes that case reachable.
>
> The restriction looks needed, since bpf_unwind_rewrite() stops walking at the
> helper frame between a callback and its caller, while the verifier would model
> the unwind continuing into the caller's frames.
>
> Could the commit message mention this restriction and the reason for it, or
> could the callback check go into its own patch?

This is not a bug as mentioned in the above. It indeed may worthwhile to
have a separate commit for callback checking since this commit is about
'refuse a landing pad that does not resume'...

>
>
> ---
> 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/37747693645