[PATCH bpf-next v4 1/3] riscv, bpf: Remap BPF_REG_0 and RV_REG_TCC
Pu Lehui
pulehui at huaweicloud.com
Sat Sep 5 01:11:08 PDT 2026
On 2026/9/5 16:00, bot+bpf-ci at kernel.org wrote:
>> diff --git a/arch/riscv/net/bpf_jit_comp64.c b/arch/riscv/net/bpf_jit_comp64.c
>> index e7378be171a9..aac128b9f0a4 100644
>> --- a/arch/riscv/net/bpf_jit_comp64.c
>> +++ b/arch/riscv/net/bpf_jit_comp64.c
>
> [ ... ]
>
>> @@ -1075,7 +1075,7 @@ int arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *ro_image,
>>
>> save_ret = flags & (BPF_TRAMP_F_CALL_ORIG | BPF_TRAMP_F_RET_FENTRY_RET);
>> if (save_ret)
>> - stack_size += 16; /* Save both A5 (BPF R0) and A0 */
>> + stack_size += 16; /* Save both T6 (BPF R0) and A0 */
>
> Should the comment read "Save both T6 (BPF R0) and A0"? The patch updates
> regmap[BPF_REG_0] from RV_REG_A5 to RV_REG_T6, and the stack slot at
> retval_off - 8 is written via regmap[BPF_REG_0] in the save_ret block
> (emit_sd(RV_REG_FP, -(retval_off - 8), regmap[BPF_REG_0], ctx)), so the
> comment still naming "A5" contradicts the new mapping. After this series
> a5 becomes an argument register (the 6th BPF argument maps to a5 in a
> later commit), which makes "A5" actively misleading here since a reader
> could mistake this slot for argument spill space rather than R0/return
> value storage.
good cache, will update
>
>
> ---
> 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/33952202002
More information about the linux-riscv
mailing list