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 8:16 AM CEST, Eduard Zingerman wrote:
> On Wed, 2026-09-23 at 04:54 +0000, Alexei Starovoitov wrote:
>> On Wed Sep 23, 2026 at 4:36 AM UTC, Kumar Kartikeya Dwivedi wrote:
>> >
>> > You can obviously insert aborts at any point in the program, provided
>> > such a primitive works, even when the compiler doesn't see it. It is
>> > just a way to halt program execution along a given path, and has
>> > plenty of precedents (assert(false), std::terminate(), panic!() =
>> > abort). That property can be used for several purposes, including
>> > proving a condition true on the other path that does not abort, and
>> > retaining that path condition throughout the rest of the program. That
>> > is basically the gist of Eduard's suggestion.
>>
>> That's only true for user space.
>> For bpf progs there is no such primitive. bpf_throw() is not it.
>> We cannot make it work from arbitrary places without introducing
>> massive verifier debt for automatic creation of exception tables
>> or via equally massive runtime penalty to remember all things to cleanup.
>
> I'm not sure that automatic exception tables would be all that more
> complex, current implementation is not that trivial either.
> Plus you mention LLMs-the-almighty yourself.
>
> But speaking of runtime costs.
> For a program like this:
>
>   main:
>     a()
>   a:
>     b()
>   b:
>     throw()
>
> The series currently generates push r6-r9 at entry to each function.
> This is needed to recover r6-r9 for the landing pads.
> See the program and disassembly below.
> Do we want to address this somehow, or is the idea that for complex
> subprograms the sequence would amortize away?
> On x86 the information about registers location at throw/landing-pad-entry
> is stored in .eh_frame section, as far as I understand.
>
> BPF:
>
>   jit_probe_b:
> 	r1 = 32;
>   1:	call bpf_throw;
>   2:	r0 = 0;
> 	exit;
>   3:	call bpf_unwind_resume;
> 	exit;
> 	CLEANUP_REC(1b, 2b, 3b)
>
>   jit_probe_a:
> 	r6 = 0x1234;
>   1:	call jit_probe_b;
>   2:	r0 = 0;
> 	exit;
>   3:	r1 = r6;
> 	call bpf_unwind_resume;
> 	exit;
> 	CLEANUP_REC(1b, 2b, 3b)
>
>   jit_probe_main:
> 	jit_probe_a();
> 	return 0;
>
> x86:
>
>   jit_probe_main:
>     0:	endbr64
>     4:	nopl	(%rax,%rax)
>     9:	nopl	(%rax)
>     c:	pushq	%rbp
>     d:	movq	%rsp, %rbp
>     10:	endbr64
>     14:	pushq	%r12
>     16:	pushq	%rbx
>     17:	pushq	%r13
>     19:	pushq	%r14
>     1b:	pushq	%r15
>     1d:	callq	0x30
>
>   jit_probe_a:
>     0:	endbr64
>     4:	nopl	(%rax,%rax)
>     9:	nopl	(%rax)
>     c:	pushq	%rbp
>     d:	movq	%rsp, %rbp
>     10:	endbr64
>     14:	pushq	%r12
>     16:	pushq	%rbx
>     17:	pushq	%r13
>     19:	pushq	%r14
>     1b:	pushq	%r15
>     1d:	movl	$0x1234, %ebx
>     22:	callq	0x9c
>     27:	endbr64
>     2b:	movq	%rbx, %rdi
>     2e:	retq
>
>   jit_probe_b:
>     0:	endbr64
>     4:	nopl	(%rax,%rax)
>     9:	nopl	(%rax)
>     c:	pushq	%rbp
>     d:	movq	%rsp, %rbp
>     10:	endbr64
>     14:	subq	$0x28, %rsp
>     1b:	pushq	%r12
>     1d:	pushq	%rbx
>     1e:	pushq	%r13
>     20:	pushq	%r14
>     22:	pushq	%r15
>     24:	movl	$0x20, %edi
>     29:	movq	%r15, -0x28(%rbp)
>     2d:	movq	%r14, -0x20(%rbp)
>     31:	movq	%r13, -0x18(%rbp)
>     35:	movq	%rbx, -0x10(%rbp)
>     39:	movq	%r12, -0x8(%rbp)
>     3d:	callq	0xffffffffe18c5c5c
>     42:	endbr64
>     46:	retq
>

That is really bad codegen. There might be a way to argue it's slightly ok for
x86 in terms of cost in prologue, but it looks really bad for arm64. I think we
need to find a better way of handling this...

Basically on entry to a subprog on arm64 we spill 80 bytes worth of registers,
ignoring spills around throw site which might be less problematic.

> ...