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

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

On Wed Sep 23, 2026 at 7:34 PM UTC, Kumar Kartikeya Dwivedi wrote:
> On Wed Sep 23, 2026 at 9:24 PM CEST, Andrii Nakryiko wrote:
>> On Wed, Sep 23, 2026 at 12:04 PM Eduard Zingerman <eddyz87@gmail.com> wrote:
>>>
>>> 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)
>
> We will still have UAPI, in form of new instruction, so this is less salient.
>
>>> - 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
>>>
>
> All of these do make sense.

Sorry, all I hear is a knee jerk reaction to a lot of slop.
yes. a lot of it is not needed, but invoke approach is no go.
As I said couple time [ip_start, ip_end] is not a single call insn.
libbpf patches do a bunch of unnecessary copy paste,
but that's because we didn't do insn_array support cleanly.
From libbpf pov bpf_cleanup section shouldn't be any different as
"one more section with pointers to instructions".

Sorry, we're not doing new 16-byte insn. We can chat about it
during the meeting, but I feel it will be a waste of time.
New insn doesn't reduce amount of slop.
Ed's example 1k vs 2k is a counter example.
This is just one llm vs another. Both sucked and both slop.
Just different amount of it.