linux-kernel - Re: [PATCH v3 3/6] powerpc64/bpf: Avoid tailcall restore from trampoline

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <22e06dcc5ec469f864880ccacfa910635460878396907005ba9f80f40d01779e@mail.kernel.org>
Date: Thu, 22 Jan 2026 17:20:32 +0000 (UTC)
From: bot+bpf-ci@...nel.org
To: adubey@...ux.ibm.com,bpf@...r.kernel.org,linuxppc-dev@...ts.ozlabs.org,linux-kselftest@...r.kernel.org,linux-kernel@...r.kernel.org
Cc: hbathini@...ux.ibm.com,sachinpb@...ux.ibm.com,venkat88@...ux.ibm.com,andrii@...nel.org,eddyz87@...il.com,mykolal@...com,ast@...nel.org,daniel@...earbox.net,martin.lau@...ux.dev,song@...nel.org,yonghong.song@...ux.dev,john.fastabend@...il.com,kpsingh@...nel.org,sdf@...ichev.me,haoluo@...gle.com,jolsa@...nel.org,christophe.leroy@...roup.eu,naveen@...nel.org,maddy@...ux.ibm.com,mpe@...erman.id.au,npiggin@...il.com,memxor@...il.com,iii@...ux.ibm.com,shuah@...nel.org,adubey@...ux.ibm.com,ast@...nel.org,andrii@...nel.org,daniel@...earbox.net,martin.lau@...nel.org,eddyz87@...il.com,yonghong.song@...ux.dev,clm@...a.com,ihor.solodrai@...ux.dev
Subject: Re: [PATCH v3 3/6] powerpc64/bpf: Avoid tailcall restore from trampoline

> diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
> index f3ee031edc26..9a8236d161ef 100644
> --- a/arch/powerpc/net/bpf_jit_comp.c
> +++ b/arch/powerpc/net/bpf_jit_comp.c
> @@ -662,16 +662,11 @@ static void bpf_trampoline_setup_tail_call_info(u32 *image, struct codegen_conte
>  static void bpf_trampoline_restore_tail_call_cnt(u32 *image, struct codegen_context *ctx,
>  						 int func_frame_offset, int r4_off)
>  {
> -	if (IS_ENABLED(CONFIG_PPC64)) {
> -		/* See bpf_jit_stack_tailcallcnt() */
> -		int tailcallcnt_offset = 7 * 8;
> -
> -		EMIT(PPC_RAW_LL(_R3, _R1, -tailcallcnt_offset));
> -		EMIT(PPC_RAW_STL(_R3, _R1, func_frame_offset - tailcallcnt_offset));
> -	} else {
> -		/* See bpf_jit_stack_offsetof() and BPF_PPC_TC */
> -		EMIT(PPC_RAW_STL(_R4, _R1, r4_off));
> -	}
> +	/*
> +	 * Restore tailcall for 32-bit ppc.
> +	 * See bpf_jit_stack_offsetof() and BPF_PPC_TC
> +	 */
> +	EMIT(PPC_RAW_STL(_R4, _R1, r4_off));
>  }

After this change, on PPC64, the function unconditionally emits
EMIT(PPC_RAW_STL(_R4, _R1, r4_off)). However, r4_off is only assigned a value
in __arch_prepare_bpf_trampoline() when IS_ENABLED(CONFIG_PPC32), and is
initialized to 0 otherwise. Since __arch_prepare_bpf_trampoline() returns
early with -EOPNOTSUPP for PPC32, only PPC64 executes this code, meaning
r4_off will always be 0.

On PPC64, PPC_RAW_STL maps to PPC_RAW_STD. Will this emit a store of R4 to
offset 0 from R1, which is the stack back chain location? The comment says
"Restore tailcall for 32-bit ppc" but the code runs unconditionally on all
architectures.

Looking at bpf_trampoline_setup_tail_call_info() in the same file, it properly
handles the two architectures using if (IS_ENABLED(CONFIG_PPC64)). Should this
restore function have a similar guard, or return early for PPC64 since the
back propagation is no longer needed?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/21257691486