linux-kernel - Re: [PATCH 2/6] powerpc64/bpf: Tailcall handling with trampolines

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: <24d8437d-3227-4abd-a31b-e6f03f4d7414@linux.ibm.com>
Date: Mon, 12 Jan 2026 00:13:16 +0530
From: Hari Bathini <hbathini@...ux.ibm.com>
To: bot+bpf-ci@...nel.org, adubey@...ux.ibm.com, bpf@...r.kernel.org,
        linuxppc-dev@...ts.ozlabs.org, linux-kselftest@...r.kernel.org,
        linux-kernel@...r.kernel.org
Cc: 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, martin.lau@...nel.org,
        clm@...a.com, ihor.solodrai@...ux.dev
Subject: Re: [PATCH 2/6] powerpc64/bpf: Tailcall handling with trampolines



On 05/01/26 4:45 pm, bot+bpf-ci@...nel.org wrote:
>> diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
>> index 069a8822c30d..4aaa0a287a45 100644
>> --- a/arch/powerpc/net/bpf_jit_comp.c
>> +++ b/arch/powerpc/net/bpf_jit_comp.c
> 
> [ ... ]
> 
>> -static void bpf_trampoline_setup_tail_call_cnt(u32 *image, struct codegen_context *ctx,
>> -					       int func_frame_offset, int r4_off)
>> +static void bpf_trampoline_setup_tail_call_info(u32 *image, struct codegen_context *ctx,
>> +					       int func_frame_offset,
>> +					       int bpf_dummy_frame_size, int r4_off)
>>   {
>>   	if (IS_ENABLED(CONFIG_PPC64)) {
>>   		/* See bpf_jit_stack_tailcallinfo_offset() */
>> -		int tailcallcnt_offset = 7 * 8;
>> +		int tailcallinfo_offset = BPF_PPC_STACK_SAVE + SZL;
> 
> [ ... ]
> 
>> +		EMIT(PPC_RAW_STL(_R3, _R1, func_frame_offset
>> +				- bpf_dummy_frame_size - tailcallinfo_offset));
>                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> The new setup function stores tail_call_info at offset
> (func_frame_offset - bpf_dummy_frame_size - tailcallinfo_offset) from R1.
> Since func_frame_offset = bpf_dummy_frame_size + bpf_frame_size, this
> resolves to (bpf_frame_size - 56), which is a positive offset from R1.

With this patchset, back propagation of tail call count is not needed
anymore, as tail call count is saved only at one place and all 
subsequent uses only hold the pointer to it. So, I can't think of a
good reason to restore tailcall count. Restore can be skipped?

@abhishek, a comment explaining how tailcall count/pointer is being
setup would help here...

Also, the trampoline frame has increased by as much as the size of
the redzone for bpf program. We are doing that just to keep tailcall
info at the same offset. No reason to save the NVRs in this frame
though. I suggest to adjust the stack layout to have tailcall info
as the first doubleword in the redzone instead of being the (n+1)th
doubleword after n NVRs. Saves stack space and makes tailcall info
offset calculation simpler.

- Hari