Re: [PATCH bpf-next v2 1/2] bpf, riscv: Add BPF stack arguments support for RV64 JIT
Feng Jiang <[email protected]>
| Newsgroups | dev.linux.lists.llvm,org.infradead.lists.linux-riscv,org.kernel.vger.bpf,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest |
|---|---|
| Message-ID | <[email protected]> |
On 2026/8/13 16:25, [email protected] wrote: >> bpf, riscv: Add BPF stack arguments support for RV64 JIT >> >> Add bpf_jit_supports_stack_args() for the RV64 JIT so BPF subprograms >> and kfuncs can receive more than 5 arguments via the stack >> (BPF_REG_PARAMS / r11). >> >> For BPF-to-BPF calls the caller writes outgoing arguments at the >> bottom of its frame (SP-relative). The callee reads them with >> FP-relative loads. Its FP is set to the caller SP in the prologue, >> so the offsets match. >> >> The RISC-V ABI puts arguments 6-8 in A5-A7 and arguments 9+ at >> SP+0. Before each kfunc call, load arguments 6-8 from the outgoing >> area into A5-A7 and copy any remaining arguments down so argument 9 >> lands at SP+0. >> >> A5 (BPF_REG_0), A6 (TCC) and A7 are safe to clobber here: R0 is not >> live before a call, TCC is backed up on the stack, and A7 is unused >> by the JIT. >> >> Limit the existing kfunc sign-extension loop to MAX_BPF_FUNC_REG_ARGS >> iterations; otherwise idx >= 5 resolves to S1-S5 (BPF_R6-FP) and >> corrupts callee-saved registers. >> >> Signed-off-by: Feng Jiang <[email protected]> > > This looks like a bug fix for stack argument support. The commit message > describes how the sign-extension loop was limited to prevent corruption > of callee-saved registers S1-S5 when idx >= 5. This fixes an issue > introduced by commit 443574b03387 ("riscv, bpf: Fix kfunc parameters > incompatibility between bpf and riscv abi"), which added the > sign-extension loop without limiting it to MAX_BPF_FUNC_REG_ARGS. > > Should this include: > > Fixes: 443574b03387 ("riscv, bpf: Fix kfunc parameters incompatibility between bpf and riscv abi") > No Fixes: tag. When 443574b03387 added the loop, the verifier still unconditionally rejected kfuncs with more than 5 args, so fm->nr_args was always <= 5 and the loop never touched S1-S5. The corruption is only reachable once this series enables stack arguments, so bounding the loop is part of the feature, not a fix for a triggerable bug. > > --- > 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/3167782391 -- With Best Regards, Feng Jiang