Re: [PATCH bpf-next v4 00/20] bpf: Run exception cleanup landing pads when bpf_throw() unwinds

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Tue Sep 22, 2026 at 1:08 AM UTC, Eduard Zingerman wrote:
> On Mon, 2026-09-21 at 14:00 -0700, Yonghong Song wrote:
>
> ...
>
>> Design
>> ======
>>
>> A pad is run, not lowered. bpf_throw() already walks the frames with
>> arch_bpf_stack_walk(); it now looks each frame's return address up in
>> that (sub)program's table and calls the pad as a subroutine of the walker,
>> with the unwinding frame's frame pointer and its callee-saved registers
>> restored from the spill its callee's prologue left. The pad therefore sees
>> its own frame but runs on the walker's stack, far below it, so nothing it
>> calls can disturb the frame it is cleaning up after. The JIT turns its
>> bpf_unwind_resume() into the way back to the walker.
>>
>> The verifier walks the same thing, step for step, so the resource rules
>> are unchanged: whatever a pad releases is released in the verifier state
>> too, and check_resource_leak() simply moves from "a throw was seen" to the
>> end of the walk.
>
> I have two high-level questions.
>
> 1) The tables handling mechanics adds quite a lot of code to the
>    libbpf and initial verification phases, while at the IR level
>    it is basically an encoding for the invoke instruction:
>
>      invoke <target-function>
>          to label <where-to-go-on-return>
>      unwind label <where-to-go-on-unwind>
>
>    For the sake of discussion, wouldn't it be simpler for us to
>    just add a 16-byte invoke instruction:
>
>     word #0:
>       code     INVOKE
>       dst_reg  0
>       src_reg  BPF_PSEUDO_CALL or BPF_PSEUDO_KFUNC_CALL
>       off      existing call meaning, including kfunc BTF fd index
>       imm      existing call-target encoding
>
>     word #1:
>       code, dst_reg, src_reg, off = 0
>       imm      signed unwind displacement, measured in 8-byte slots
>
>    With an assumption that during normal execution (not unwinding)
>    upon return from invoke the control flow goes to a fallthrough
>    instruction.
>
>    The pros are:
>    - much less frontend code
>    - if in the future we would like to manipulate BPF program
>      byte code, it would be significantly simpler to do in such form.

I think the amount of code will increase a lot more with such approach.
All existing call flavors and my new callx would need to wrapped
with this new 'invoke' insn.
Also rust generates begin/end across more than single insn.

>    [1] https://llvm.org/docs/LangRef.html#i-invoke
>
> 2) The final goal of the BPF/Rust project is to consume whatever code
>    rustc generates. Ultimately, this would require supporting a way
>    to introduce runtime checks at arbitrary locations, whenever the
>    verifier can't infer that the program is safe. 

so far all rustc code looks clean and definitely not arbitrary.

> Such checks won't
>    necessarily have associated landing pads. Meaning that the unwinding

no landing pad? what? That's not rustc.
You're talking about some random compiler that throws garbage.

>    logic will have to be dynamic as in exceptions part #2 sense discussed
>    way back (2022?).
>
>    The argument against exceptions part #2 back then was that the code
>    is complex. Given the current environment, I don't think the argument
>    still holds.
>
>    Hence, given that dynamic abort would be necessary, and that the kernel's
>    rust code is already compiled with -Cpanic=abort, do we need this static
>    form of exceptions handling at all?

This patch is static exception handling for cases where compiler generated them.

We don't know and don't care what is in those landing pads.
rustc maybe cleaning up the objects that have no meaning for the verifier.
Maybe freeing memory (but since it's arena) we don't care,
but we will still call all the drop()s because that's what rust as a language
promised to users and we cannot break that promise.
kernel's rust with panic=abort needs to be fixed.
That's orthogonal problem and definitely not something to follow.