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 17:04 -0700, Eduard Zingerman wrote:
> 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

I want to highlight this once more, before it gets buried.

Whether landing pad is metadata or not is a matter of opinion,
seeing the program CFG from it's source w/o a need to consult
additional tables is definitely a plus.
Same with ld_imm64, and yes it adds a few checks in the verifier,
but those checks are trivial.

I looked a bit at what other VMs/IRs do and it's a mix:
- JVM has exception tables similar to ours (begin, end, landing-pad).
- GCC (gimple and rtl) have landing pad address attached to an
  instruction / control flow graph node.
- LLVM has invoke instruction that takes three parameters:
  what to call, where to jump on success, where to jump to unwind.

With that in mind, I think that the rational thing to do is to choose
based on the implementation complexity. Compared to v5 [2] of this
series the branch [1] allows to forgo:
- UAPI to copy the cleanup table from user space (patch #2)
- insn_aux_data changes for cleanup_pad address (patch #4)
- simplifies check_cfg() handling (patch #5)
- simplifies main verification pass (patch #9):
  - throw raises unwinding flag
  - varifier interprets `unwind` as any other instruction,
	jump if unwinding, fallthrough during normal operation.
- dramatically simplifies libbpf part, dropping patches #16,17,18:
  - no need to collect cleanup tables from elf
  - no need to relocate these tables
  - no need to pass them to the syscall

> bpf ISA is not a high level IR.

Well, BPF evolved as x86 in disguise and it was the right choice for
that moment in time. Today it is a limiting factor, just talking about
explicit stack vs SSA, it makes it harder to:
- do liveness analysis
- do range analysis
- do SCEV analysis
- use full set of registers on e.g. ARM
- the fastcall implementation is a hack

So, BPF not being a high level IR is not necessarily a good thing.

[1] https://github.com/eddyz87/bpf/tree/unwind-postfix
[2] https://lore.kernel.org/bpf/20260923045846.2414643-1-yonghong.song@linux.dev/