From: Hari Bathini <hbathini@linux.ibm.com>
To: bot+bpf-ci@kernel.org, adubey@linux.ibm.com, bpf@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: sachinpb@linux.ibm.com, venkat88@linux.ibm.com,
andrii@kernel.org, eddyz87@gmail.com, mykolal@fb.com,
ast@kernel.org, daniel@iogearbox.net, martin.lau@linux.dev,
song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, christophe.leroy@csgroup.eu,
naveen@kernel.org, maddy@linux.ibm.com, mpe@ellerman.id.au,
npiggin@gmail.com, memxor@gmail.com, iii@linux.ibm.com,
shuah@kernel.org, martin.lau@kernel.org, clm@meta.com,
ihor.solodrai@linux.dev
Subject: Re: [PATCH v4 6/6] powerpc64/bpf: Additional NVR handling for bpf_throw
Date: Fri, 23 Jan 2026 18:47:51 +0530 [thread overview]
Message-ID: <b35dab8c-7e6b-4b7a-ac77-b85e33051e95@linux.ibm.com> (raw)
In-Reply-To: <e63a916bd44b8352aace4fd47fdeb459dc75cceb71615f44e6234cc1b6ffbd69@mail.kernel.org>
On 23/01/26 3:10 am, bot+bpf-ci@kernel.org wrote:
>> diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
>> index c284a12fce6e..98780a15fc69 100644
>> --- a/arch/powerpc/net/bpf_jit_comp64.c
>> +++ b/arch/powerpc/net/bpf_jit_comp64.c
>
> [ ... ]
>
>> @@ -125,9 +149,19 @@ int bpf_jit_stack_tailcallinfo_offset(struct codegen_context *ctx)
>>
>> static int bpf_jit_stack_offsetof(struct codegen_context *ctx, int reg)
>> {
>> - if (reg >= BPF_PPC_NVR_MIN && reg < 32)
>> + int min_valid_nvreg = BPF_PPC_NVR_MIN;
>> + /* Default frame size for all cases except exception boundary */
>> + int frame_nvr_size = BPF_PPC_STACKFRAME;
>> +
>> + /* Consider all nv regs for handling exceptions */
>> + if (ctx->exception_boundary || ctx->exception_cb) {
>> + min_valid_nvreg = _R14;
>> + frame_nvr_size = BPF_PPC_EXC_STACKFRAME;
>> + }
>> +
>> + if (reg >= min_valid_nvreg && reg < 32)
>> return (bpf_has_stack_frame(ctx) ?
>> - (BPF_PPC_STACKFRAME + ctx->stack_size) : 0)
>> + (frame_nvr_size + ctx->stack_size) : 0)
>> - (8 * (32 - reg)) - BPF_PPC_TAILCALL;
>
> For the redzone case (no stack frame) with exception_boundary, this
> formula computes R23 at offset -80 and R24 at offset -72 from R1.
>
> However, bpf_stf_barrier() uses hardcoded offsets -80(1) and -72(1) to
> temporarily save R21 and R22 during STF barrier execution:
>
> asm (
> " bpf_stf_barrier: ;"
> " std 21,-80(1) ;"
> " std 22,-72(1) ;"
> " sync ;"
> " ld 21,-80(1) ;"
> " ld 22,-72(1) ;"
> ...
> );
>
> When an exception_boundary program without its own stack frame executes a
> memory load that triggers STF_BARRIER_FALLBACK, can bpf_stf_barrier()
> corrupt the saved R23 and R24 values? The hardcoded offsets would overlap
> with the extended NVR save area.
>
> If exception_cb later restores these registers, it would get R21/R22 values
> instead of the original R23/R24 values.
>
That is practically not possible as exception_boundary would mean
at least bpf_throw() is in the program (SEEN_FUNC) and SEEN_FUNC
would setup a frame for the exception_boundary program. Also,
bpf_stf_barrier() always uses the redzone. So, it never stomps
on the stack of exception_boundary program...
@abhishek, better add the above comment and probably
also make bpf_has_stack_frame() return true explicitly for
exception_boundary as well (though SEEN_FUNC can't be false
in case of exception_boundary)..
- Hari
prev parent reply other threads:[~2026-01-23 13:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-22 21:18 [PATCH v4 0/6] powerpc64/bpf: Support tailcalls with subprogs & BPF exceptions adubey
2026-01-22 21:18 ` [PATCH v4 1/6] powerpc64/bpf: Moving tail_call_cnt to bottom of frame adubey
2026-01-23 12:45 ` Hari Bathini
2026-01-22 21:18 ` [PATCH v4 2/6] powerpc64/bpf: Support tailcalls with subprogs adubey
2026-01-23 12:48 ` Hari Bathini
2026-01-22 21:18 ` [PATCH v4 3/6] powerpc64/bpf: Avoid tailcall restore from trampoline adubey
2026-01-22 21:18 ` [PATCH v4 4/6] powerpc64/bpf: Add arch_bpf_stack_walk() for BPF JIT adubey
2026-01-23 12:51 ` Hari Bathini
2026-01-22 21:18 ` [PATCH v4 5/6] powerpc64/bpf: Support exceptions adubey
2026-01-23 12:54 ` Hari Bathini
[not found] ` <9f35f6799b0b27866259582a2eefecb3@imap.linux.ibm.com>
2026-01-23 18:13 ` Hari Bathini
2026-01-22 21:18 ` [PATCH v4 6/6] powerpc64/bpf: Additional NVR handling for bpf_throw adubey
2026-01-22 21:40 ` bot+bpf-ci
2026-01-23 13:17 ` Hari Bathini [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b35dab8c-7e6b-4b7a-ac77-b85e33051e95@linux.ibm.com \
--to=hbathini@linux.ibm.com \
--cc=adubey@linux.ibm.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bot+bpf-ci@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=clm@meta.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=ihor.solodrai@linux.dev \
--cc=iii@linux.ibm.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=martin.lau@kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=mpe@ellerman.id.au \
--cc=mykolal@fb.com \
--cc=naveen@kernel.org \
--cc=npiggin@gmail.com \
--cc=sachinpb@linux.ibm.com \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=venkat88@linux.ibm.com \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox