All of lore.kernel.org
 help / color / mirror / Atom feed
From: adubey <adubey@linux.ibm.com>
To: Hari Bathini <hbathini@linux.ibm.com>
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	bpf@vger.kernel.org, Madhavan Srinivasan <maddy@linux.ibm.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Saket Kumar Bhaskar <skb99@linux.ibm.com>,
	Venkat Rao Bagalkote <venkat88@linux.ibm.com>,
	bot+bpf-ci@kernel.org
Subject: Re: [PATCH v2 5/5] powerpc64/bpf: fix handling of BPF stack in exception callback
Date: Tue, 24 Feb 2026 17:58:29 +0530	[thread overview]
Message-ID: <63a682779fd92c0a027de1b83581abc3@linux.ibm.com> (raw)
In-Reply-To: <20260220063933.196141-6-hbathini@linux.ibm.com>

On 2026-02-20 12:09, Hari Bathini wrote:
> Exception callback reuses the stack frame of exception boundary. When
> exception boundary and exception callback programs have different BPF
> stack depth, the current stack unwind in exception callback will fail.
> Adjust the stack frame size of exception callback, in its prologue,
> if its BPF stack depth is different from that of exception boundary.
> 
> Reported-by: bot+bpf-ci@kernel.org
> Closes:
> https://lore.kernel.org/bpf/2a310e86a59eb4c44c3ac9e5647814469d9c955580c9c0f1b3d9ca4a44717a34@mail.kernel.org/
> Fixes: 11d45eee9f42 ("powerpc64/bpf: Additional NVR handling for 
> bpf_throw")
> Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
> ---
> 
> Changes since v1:
> * Fixed incorrect use of PPC_RAW_SUB() as pointed out by
>   bot+bpf-ci@kernel.org.
> 
> 
>  arch/powerpc/net/bpf_jit_comp64.c | 30 ++++++++++++++++++++++--------
>  1 file changed, 22 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/powerpc/net/bpf_jit_comp64.c
> b/arch/powerpc/net/bpf_jit_comp64.c
> index 5d4d2bb23cef..33b2a7fd9067 100644
> --- a/arch/powerpc/net/bpf_jit_comp64.c
> +++ b/arch/powerpc/net/bpf_jit_comp64.c
> @@ -32,14 +32,15 @@
>   *
>   *		[	prev sp		] <-------------
>   *		[    tail_call_info	] 8		|
> - *		[   nv gpr save area	] 6*8 + (12*8)	|
> + *		[   nv gpr save area	] 6*8		|
> + *		[ addl. nv gpr save area] (12*8)	| <--- exception 
> boundary/callback program
>   *		[    local_tmp_var	] 24		|
>   * fp (r31) -->	[   ebpf stack space	] upto 512	|
>   *		[     frame header	] 32/112	|
>   * sp (r1) --->	[    stack pointer	] --------------
>   *
>   * Additional (12*8) in 'nv gpr save area' only in case of
> - * exception boundary.
> + * exception boundary/callback.
>   */
> 
>  /* BPF non-volatile registers save area size */
> @@ -128,12 +129,13 @@ static inline bool bpf_has_stack_frame(struct
> codegen_context *ctx)
>   *		[	  ...       	] 		|
>   * sp (r1) --->	[    stack pointer	] --------------
>   *		[    tail_call_info	] 8
> - *		[   nv gpr save area	] 6*8 + (12*8)
> + *		[   nv gpr save area	] 6*8
> + *		[ addl. nv gpr save area] (12*8) <--- exception boundary/callback 
> program
>   *		[    local_tmp_var	] 24
>   *		[   unused red zone	] 224
>   *
>   * Additional (12*8) in 'nv gpr save area' only in case of
> - * exception boundary.
> + * exception boundary/callback.
>   */
>  static int bpf_jit_stack_local(struct codegen_context *ctx)
>  {
> @@ -240,10 +242,6 @@ void bpf_jit_build_prologue(u32 *image, struct
> codegen_context *ctx)
> 
>  	if (bpf_has_stack_frame(ctx) && !ctx->exception_cb) {
>  		/*
> -		 * exception_cb uses boundary frame after stack walk.
> -		 * It can simply use redzone, this optimization reduces
> -		 * stack walk loop by one level.
> -		 *
>  		 * We need a stack frame, but we don't necessarily need to
>  		 * save/restore LR unless we call other functions
>  		 */
> @@ -287,6 +285,22 @@ void bpf_jit_build_prologue(u32 *image, struct
> codegen_context *ctx)
>  		 * program(main prog) as third arg
>  		 */
>  		EMIT(PPC_RAW_MR(_R1, _R5));
> +		/*
> +		 * Exception callback reuses the stack frame of exception boundary.
> +		 * But BPF stack depth of exception callback and exception boundary
> +		 * don't have to be same. If BPF stack depth is different, adjust 
> the
> +		 * stack frame size considering BPF stack depth of exception 
> callback.
> +		 * The non-volatile register save area remains unchanged. These non-
> +		 * volatile registers are restored in exception callback's epilogue.
> +		 */
> +		EMIT(PPC_RAW_LD(bpf_to_ppc(TMP_REG_1), _R5, 0));
> +		EMIT(PPC_RAW_SUB(bpf_to_ppc(TMP_REG_2), bpf_to_ppc(TMP_REG_1), 
> _R1));
> +		EMIT(PPC_RAW_ADDI(bpf_to_ppc(TMP_REG_2), bpf_to_ppc(TMP_REG_2),
> +			-BPF_PPC_EXC_STACKFRAME));
> +		EMIT(PPC_RAW_CMPLDI(bpf_to_ppc(TMP_REG_2), ctx->stack_size));
> +		PPC_BCC_CONST_SHORT(COND_EQ, 12);
> +		EMIT(PPC_RAW_MR(_R1, bpf_to_ppc(TMP_REG_1)));
> +		EMIT(PPC_RAW_STDU(_R1, _R1, -(BPF_PPC_EXC_STACKFRAME + 
> ctx->stack_size)));
For the last comment here:
"Do we need to setup FP again? If I get it right, still the FP is 
pointing to older frame, any reference in
callback will resolve to old frame."

Following inst takes care of above; it was missing for me in rebasing, 
my bad.
EMIT(PPC_RAW_ADDI(bpf_to_ppc(BPF_REG_FP), _R1,
                                 STACK_FRAME_MIN_SIZE + 
ctx->stack_size));

>  	}
> 
>  	/*
-Abhishek

      parent reply	other threads:[~2026-02-24 12:28 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-20  6:39 [PATCH v2 0/5] powerpc64/bpf: various fixes Hari Bathini
2026-02-20  6:39 ` [PATCH v2 1/5] powerpc64/bpf: do not increment tailcall count when prog is NULL Hari Bathini
2026-02-21  3:40   ` Venkat Rao Bagalkote
2026-02-20  6:39 ` [PATCH v2 2/5] powerpc64/bpf: fix the address returned by bpf_get_func_ip Hari Bathini
2026-02-21  3:41   ` Venkat Rao Bagalkote
2026-02-22 12:21   ` adubey
2026-02-20  6:39 ` [PATCH v2 3/5] powerpc64/bpf: use consistent tailcall offset in trampoline Hari Bathini
2026-02-22 13:07   ` adubey
2026-03-03 13:43     ` Hari Bathini
2026-02-20  6:39 ` [PATCH v2 4/5] powerpc64/bpf: remove BPF redzone protection in trampoline stack Hari Bathini
2026-02-21  3:43   ` Venkat Rao Bagalkote
2026-02-20  6:39 ` [PATCH v2 5/5] powerpc64/bpf: fix handling of BPF stack in exception callback Hari Bathini
2026-02-23  9:03   ` adubey
2026-03-03 13:46     ` Hari Bathini
2026-02-24 12:28   ` adubey [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=63a682779fd92c0a027de1b83581abc3@linux.ibm.com \
    --to=adubey@linux.ibm.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bot+bpf-ci@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=hbathini@linux.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=skb99@linux.ibm.com \
    --cc=venkat88@linux.ibm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.