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

[Eduard Zingerman <eddyz87@gmail.com>]

On Tue, 2026-09-22 at 02:16 +0000, Alexei Starovoitov wrote:
> 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.

Total size of executable sections for all Meta BPF object files used
for CI veristat testing is 10Mb. Of these there are 30K non-helper
call instructions in total.
So we are talking about increase by 8 * 30K = 240K ~ 2.4% worst case.
Note that the instruction encoding optimized for size already hearts
us in src/dst registers department: we have no room for virtual
registers, which would have simplified e.g. register allocation task
for ARM64. Point being that optimizing intermediate IR for size is not
always a right target.

> >    [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.

As Kartikeya says in a sibling email, I mean generic verifier
capability to accept any program by introducing runtime checks.
Verifier's capacity to infer safety conditions for various
instructions is orthogonal to rustc's assumptions about landing pad
boundaries. E.g. rustc/llvm might infer that certain memory access is
within bounds and optimize bound checks out, it is not a given that
verifier would come to a same conclusion and that some landing pad
would be declared for an instruction.