[PATCH v3 6/6] powerpc64/bpf: fix kfunc call support

[bot+bpf-ci at kernel.org]

> diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
> index 04e76440d1ad..3a6bd12eecfd 100644
> --- a/arch/powerpc/net/bpf_jit_comp64.c
> +++ b/arch/powerpc/net/bpf_jit_comp64.c

[ ... ]

> +static int zero_extend(u32 *image, struct codegen_context *ctx, u32 src_reg, u32 dst_reg, u32 size)
> +{
> +	switch (size) {
> +	case 1:
> +		 /* zero-extend 8 bits into 64 bits */
> +		EMIT(PPC_RAW_RLDICL(dst_reg, dst_reg, 0, 56));
                                           ^^^^^^^
Should this second dst_reg be src_reg instead?

PPC_RAW_RLDICL(d, a, i, mb) takes d as the destination (RA) and a as
the source (RS). All three cases here pass dst_reg as both the source
and destination operand, which means the src_reg parameter is unused.

The companion sign_extend() function in the same patch correctly uses
both parameters:

    EMIT(PPC_RAW_EXTSB(dst_reg, src_reg));

Currently prepare_for_kfunc_call() always passes the same register for
both src and dst, so the generated code is correct. But the function
signature accepts src_reg without using it, which is inconsistent with
sign_extend() and would silently produce wrong code if a future caller
passes different registers.

> +		return 0;
> +	case 2:
> +		 /* zero-extend 16 bits into 64 bits */
> +		EMIT(PPC_RAW_RLDICL(dst_reg, dst_reg, 0, 48));
> +		return 0;
> +	case 4:
> +		 /* zero-extend 32 bits into 64 bits */
> +		EMIT(PPC_RAW_RLDICL(dst_reg, dst_reg, 0, 32));

Same issue in cases 2 and 4.

> +		fallthrough;
> +	case 8:
> +		/* Nothing to do */
> +		return 0;
> +	default:
> +		return -1;
> +	}
> +}


---
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/22624805528