Re: [PATCH bpf-next v2 05/11] LoongArch: BPF: Add exceptions (bpf_throw) support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The BPF frame pointer ($r22) can be clobbered by bpf_throw() before it is captured, causing stack unwinding to fail and crash.
- [Low] Multi-line comment does not follow the required BPF kernel comment style.
--

commit a22e7d51563237179d5ffdc8ffe6290c25f1ddba
Author: George Guo <guodongtai@kylinos.cn>

LoongArch: BPF: Add exceptions (bpf_throw) support
    
This patch implements BPF exception support for LoongArch. It introduces
arch_bpf_stack_walk() to find the exception boundary frame using the ORC
unwinder, allowing bpf_throw() to properly unwind the stack and invoke
the exception callback.

> diff --git a/arch/loongarch/kernel/stacktrace.c b/arch/loongarch/kernel/stacktrace.c
> index 387dc4d3c4868..718c98b3f1fc4 100644
> --- a/arch/loongarch/kernel/stacktrace.c
> +++ b/arch/loongarch/kernel/stacktrace.c
[ ... ]
> +void arch_bpf_stack_walk(bool (*consume_fn)(void *cookie, u64 ip, u64 sp, u64 bp),
> +			 void *cookie)
> +{
> +	unsigned long fp;
> +
> +	/*
> +	 * Capture the live frame pointer ($r22/$fp) here, before handing off to
> +	 * the worker. The kernel is built with -fomit-frame-pointer, so $fp is
> +	 * an ordinary callee-saved register that is preserved across the call
> +	 * from the JITed BPF program into bpf_throw() down to here, and thus
> +	 * still points at the innermost BPF frame. The ORC frame-pointer
> +	 * fallback walks the BPF frames up to the exception boundary from it.
> +	 *
> +	 * This must be a thin wrapper with no large stack locals: the worker
> +	 * uses $r22 to address its frame, which would clobber the live $fp
> +	 * before it could be read. __builtin_frame_address() cannot be used
> +	 * either, as it is $sp-derived and would yield a kernel-stack frame.
> +	 */
> +	asm volatile("move %0, $r22" : "=r"(fp));
> +	walk_stackframe_bpf(consume_fn, cookie, fp);
> +}

[Severity: High]
Can the C compiler clobber the BPF frame pointer ($r22) before this inline
assembly captures it? 

Because the kernel is built with -fomit-frame-pointer, the compiler is free to
use $r22 as a general-purpose callee-saved register. If the intermediate C 
caller (bpf_throw) modifies $r22 during its execution, this assembly will 
capture the clobbered value instead of the BPF frame pointer.

If the frame pointer is clobbered, the ORC unwinder will fail to find the
exception boundary, leaving ctx.aux as NULL. bpf_throw() then unconditionally
dereferences ctx.aux, which would cause a kernel panic.

> diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c
> index 3822e05a07790..f172ffc2c011c 100644
> --- a/arch/loongarch/net/bpf_jit.c
> +++ b/arch/loongarch/net/bpf_jit.c
> @@ -29,16 +29,20 @@
>  
>  static int tail_call_cnt_ptr_stack_off(struct jit_ctx *ctx)
>  {
[ ... ]
> -	/* An arena program reserves one extra word above them (REG_ARENA),
> -	 * which pushes the tail call count pointer down by one slot.
> +	/* An arena or exception program reserves one extra word above them
> +	 * ($s6, see build_prologue()), which pushes the tail call count
> +	 * pointer down by one slot.
>  	 */

[Severity: Low]
This isn't a bug, but does this multi-line comment follow the BPF subsystem
comment style? The BPF subsystem requires the opening /* of a multi-line
comment to be on its own line.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260702022322.51033-1-dongtai.guo@linux.dev?part=5