Re: [RFC PATCH 3/3] LoongArch: BPF: Inline bpf_get_smp_processor_id() helper

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The inlined `bpf_get_smp_processor_id` helper uses a sign-extending load (`ldw`) instead of a zero-extending load (`ldwu`).
--

commit 537ce2d4859db91089b968d6b560566858b53b6f
Author: Tiezhu Yang <yangtiezhu@loongson.cn>

LoongArch: BPF: Inline bpf_get_smp_processor_id() helper

This commit inlines the bpf_get_smp_processor_id() helper into a single
load instruction on LoongArch. It accesses the thread_info which is always
available in the thread pointer register.

> diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c
> index b93b67d22c26..b1c6194c4099 100644
> --- a/arch/loongarch/net/bpf_jit.c
> +++ b/arch/loongarch/net/bpf_jit.c

[ ... ]

> @@ -1154,6 +1155,12 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx, bool ext
>  			break;
>  		}
>  
> +		/* Implement helper call to bpf_get_smp_processor_id() inline */
> +		if (insn->src_reg == 0 && insn->imm == BPF_FUNC_get_smp_processor_id) {
> +			emit_insn(ctx, ldw, regmap[BPF_REG_0], LOONGARCH_GPR_TP, TI_CPU);

Does this code need to use a zero-extending load (ldwu) instead of a
sign-extending load (ldw)?

The C implementation of bpf_get_smp_processor_id() returns a u64, meaning
the 32-bit smp_processor_id() result is zero-extended to 64 bits.

While CPU IDs are small positive integers so sign-extending and
zero-extending produce the same result in practice, using the
zero-extending ldwu would strictly match the BPF calling convention and
original C helper semantics.

> +			break;
> +		}
> +
>  		ret = bpf_jit_get_func_addr(ctx->prog, insn, extra_pass,
>  					    &func_addr, &func_addr_fixed);
>  		if (ret < 0)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260428072021.7289-1-yangtiezhu@loongson.cn?part=3