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

["Kumar Kartikeya Dwivedi" <memxor@gmail.com>]

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.

>
> All of the above sounds like a pretty compelling reason to do the
> invoke instruction. 16-byte instructions is a fact of life due to
> ldimm64 anyways, might as well utilize those extended instructions to
> simplify a bunch of other stuff. Not having a bunch of arbitrary
> ELF-side conventions is a big plus, IMO.
>

IIUC we just need extra unwind following the call, since it already has two
control flow edges (target and fallthrough for what it would return to), so
it might be simpler than full blown new invoke.

But yeah, we didn't shy away from adding bespoke instructions when it suited us
(may_goto, etc.) in the past.

> Unless there are some technical reasons why metadata table on the side
> is objectively better, but seeing that we have precedents with LLVM
> using same approach, seems like it's workable and shouldn't paint us
> into the corner design-wise, no?
>
> Given a rather lively interest and discussion, perhaps we should do
> one of those long forgotten BPF office hours and go over this in a
> more face-to-face-ish way?
>
>> > bpf ISA is not a high level IR.
>> [...]