Re: [PATCH v4 bpf-next 2/6] bpf, x86: Support unwind_goto and unwind_exit

[Nathan Chancellor <nathan@kernel.org>]

Hi Alexei,

On Tue, Oct 20, 2026 at 06:13:16PM +0000, Alexei Starovoitov wrote:
> From: Alexei Starovoitov <ast@kernel.org>
> 
>   bpf                         x86
>   call inner                  call inner
>   unwind_goto pad
>   w0 = w6                     mov eax, ebx
> 
>   r0 = 0                      xor eax, eax
>   unwind_exit                 push rax
>                               push rsi
>                               mov rdi, [rbp + 8]
>                               call bpf_unwind_target
>                               mov [rbp + 8], rax
>                               pop rsi
>                               pop rax
>                               leave
>                               ret
> 
> unwind_goto is an extable entry and no code. unwind_exit looks its return
> address up there and returns to the pad. r0 and r2 are what a subprog
> returns, so rax and rsi are saved around the lookup.
> 
> When there is no entry, the kernel called the subprog as an async or an
> exception callback, and unwind_exit is exit.
> 
> The caller of the main prog doesn't tell exit from unwind_exit, so there
> it's exit. An extension is different. freplace is a jump, so its return
> address is the one of the subprog that it replaced.
> 
> With private stack r9 is saved around a call, and 'pop r9' has to be done
> on the way to the pad too. In such progs unwind_goto is:
> 
>   push r9
>   call foo
>   pop r9       <- exit returns here
>   jmp 1f
>   pop r9       <- unwind_exit returns here
>   jmp pad
> 1:
> 
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>

After this change landed in -next as commit cff94a3d78d8 ("bpf, x86:
Support unwind_goto and unwind_exit"), I am seeing the following objtool
warning when building with LLVM 23.1.4 and a recent tip of tree version
of LLVM 24 with the attached configuration (which can become an error
with CONFIG_OBJTOOL_WERROR):

  vmlinux.o: warning: objtool: do_jit+0x1330: relocation to !ENDBR: .text+0xc7fab

Something like the below diff appears to inhibit this but I am not sure
if it is too big of a hammer or if there is a better solution, hence
just the report and deferring to you, but maybe it is a good starting
point.

diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index d3ab36281144..b80f05f377c2 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -641,6 +641,7 @@ static int emit_patch(u8 **pprog, void *func, void *ip, u8 opcode)
 
 static int emit_call(u8 **pprog, void *func, void *ip)
 {
+	OPTIMIZER_HIDE_VAR(func);
 	return emit_patch(pprog, func, ip, 0xE8);
 }
 
-- 
Cheers,
Nathan