bpf, riscv: Add BPF stack arguments support for RV64 JIT

[kernel-patches-daemon-bpf]

Pull request for series with
subject: bpf, riscv: Add BPF stack arguments support for RV64 JIT
version: 3
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=1145772

[kernel-patches-daemon-bpf]

Upstream branch: 4d9551b
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1145772
version: 3

[kernel-patches-review-bot]

commit 8f86ad1c97a0ca38d816acf9b543e814ad4efb18
Author: Feng Jiang <jiangfeng@kylinos.cn>

bpf, riscv: Add BPF stack arguments support for RV64 JIT

This patch enables BPF stack arguments for the RV64 JIT, allowing
subprograms and kfuncs to receive more than 5 arguments. For BPF-to-BPF
calls, arguments are passed via memory (caller stores at SP, callee reads
at FP). For kfunc calls, arguments 6-8 are loaded into A5-A7 and
remaining arguments are copied down to match the RISC-V ABI.

> diff --git a/arch/riscv/net/bpf_jit_comp64.c b/arch/riscv/net/bpf_jit_comp64.c
> index 2504df1fa1118..62c84de22163f 100644
> --- a/arch/riscv/net/bpf_jit_comp64.c
> +++ b/arch/riscv/net/bpf_jit_comp64.c

[ ... ]

> @@ -1891,6 +1916,21 @@ int bpf_jit_emit_insn
>  	case BPF_LDX | BPF_MEM | BPF_H:
>  	case BPF_LDX | BPF_MEM | BPF_W:
>  	case BPF_LDX | BPF_MEM | BPF_DW:
> +		if (insn->src_reg == BPF_REG_PARAMS) {
> +			int idx = off / 8 - 1;
> +
> +			if (is_12b_int(idx * 8)) {
> +				emit_ldx_insn(rd, idx * 8, RV_REG_FP, BPF_SIZE(code), false, ctx);
> +			} else {
> +				emit_imm(RV_REG_T1, idx * 8, ctx);
> +				emit_add(RV_REG_T1, RV_REG_T1, RV_REG_FP, ctx);
> +				emit_ldx_insn(rd, 0, RV_REG_T1, BPF_SIZE(code), false, ctx);
> +			}
> +			if (BPF_SIZE(code) != BPF_DW && insn_is_zext(&insn[1]))
> +				return 1;
> +			break;
> +		}
> +		fallthrough;

Does this new BPF-to-BPF stack argument convention work correctly with
the existing RV64 trampoline code?

The convention here reads incoming stack arguments from FP+0, FP+8, etc
(callee FP == caller SP). But looking at store_args() in this same file,
the trampoline appears to use the native RISC-V ABI instead:

arch/riscv/net/bpf_jit_comp64.c:store_args() {
    for (i = 0; i < nr_arg_slots; i++) {
        if (i < RV_MAX_REG_ARGS)
            emit_sd(RV_REG_FP, -args_off, RV_REG_A0 + i, ctx);
        else
            emit_ld(RV_REG_T1, 16 + (i - RV_MAX_REG_ARGS) * 8, RV_REG_FP, ctx);

where RV_MAX_REG_ARGS is 8, so it expects arguments 6, 7, 8 in a5, a6, a7
and arguments 9+ at FP+16.

For a BPF subprogram using this new convention, arguments 6+ arrive in
memory, not in a5-a7. When an fentry or fexit program attaches to such a
subprogram, wouldn't it read unrelated register values instead of the real
arguments?

Both arm64 and x86-64 appear to avoid this by keeping their BPF stack
argument convention identical to their native ABIs. arm64 uses
`stack_arg_reg[] = { A64_R(5), A64_R(6), A64_R(7) }` and x86-64 keeps arg6
in r9, so their trampolines work without changes.

Can fentry/fexit attach to static BPF subprograms with more than 5
arguments, or is there a verifier check that prevents this?

[ ... ]

---

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

In-Reply-To-Subject: bpf, riscv: Add BPF stack arguments support for RV64 JIT
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/31761418445

[kernel-patches-daemon-bpf]

Forwarding comment 5288747708 via email
In-Reply-To: 20260814-bpf-riscv-stack-args-v3-1-2160de56fea3@kylinos.cn
Patch: https://patchwork.kernel.org/project/netdevbpf/patch/20260814-bpf-riscv-stack-args-v3-1-2160de56fea3@kylinos.cn/

[kernel-patches-daemon-bpf]

Upstream branch: 409a9bd
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1145772
version: 3

[kernel-patches-daemon-bpf]

Upstream branch: c7e6175
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1145772
version: 3

[kernel-patches-daemon-bpf]

Upstream branch: f2aaa62
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1145772
version: 3

[kernel-patches-daemon-bpf]

Upstream branch: f2aaa62
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1145772
version: 3

[kernel-patches-daemon-bpf]

Upstream branch: 90bd032
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1145772
version: 3

[kernel-patches-daemon-bpf]

Upstream branch: a2b83a8
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1145772
version: 3

[kernel-patches-daemon-bpf]

Upstream branch: fdd4fad
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1145772
version: 3

[kernel-patches-daemon-bpf]

Upstream branch: 8eb1892
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1145772
version: 3

[kernel-patches-daemon-bpf]

Upstream branch: d99bda7
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1145772
version: 3

[kernel-patches-daemon-bpf]

Upstream branch: 34e0eb7
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1145772
version: 3

[kernel-patches-daemon-bpf]

Upstream branch: 5fe7007
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1145772
version: 3

[kernel-patches-daemon-bpf]

Upstream branch: 77877bf
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1145772
version: 3

[kernel-patches-daemon-bpf]

Upstream branch: adb7719
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1145772
version: 3

[kernel-patches-daemon-bpf]

Upstream branch: 6b0835a
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1145772
version: 3

[kernel-patches-daemon-bpf]

Upstream branch: 6ab6a94
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1145772
version: 3