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 23:37 +0000, Alexei Starovoitov wrote:
> On Tue Sep 22, 2026 at 11:08 PM UTC, Eduard Zingerman wrote:
> > 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.
> 
> Any new insn requires plumbing through out.
> imo ld_imm64 encoding FD inline was a mistake.
> We should have went with relocations through out.
> Much cleaner to extend.
> Same philosophy here. Landing pad is a metadata.
> It's not a good idea to encode metadata into assembly instruction.
> bpf ISA is not a high level IR.

Here [1] is Yonghong's series repackaged by codex with the following
encoding:

  call <subprog-or-kfunc> // regular encoding
  unwind <label>          // a new instruction that must follow the call instruction

The amount of the verifier/libbpf code dropped from ~2K to 1K lines.

[1] https://github.com/eddyz87/bpf/tree/unwind-postfix

> > Do we have a working toolchain somewhere? I can work a few examples.
> 
> Please send SCEV upstream asap. This is way more important
> then arguing over this bits.