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 21:47 +0000, Alexei Starovoitov wrote:
> On Tue Sep 22, 2026 at 4:27 AM UTC, Eduard Zingerman wrote:
> > 
> > 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.
> 
> I wasn't talking about increase in bpf ELF size,
> but the amount of the verifier work necessary to double the number
> of call insns.

I don't understand what you mean by the amount of the verifier work.
Traced program paths would remain the same, only the encoding of the
information about exceptions changes.

> > 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.
> 
> Replied to Kumar. I don't think the verifier will ever insert
> runtime checks with control flow at random points.
> If we teach rustc to insert may_goto then it will be done
> at rustc/llvm level. Not by the verifier.

Fighting the verifier after rustc transformations would be especially fun.
Do we have a working toolchain somewhere? I can work a few examples.