Re: [PATCH bpf v9 6/8] selftest/bpf: Add tailcall verifier selftest for powerpc64

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] JIT disasm regex for loading 64-bit immediates strictly expects 'oris' and 'ori' instructions, but the PowerPC JIT conditionally omits them.
- [Medium] JIT disasm regex for BPF-to-BPF tail calls fails on PowerPC kernels with CONFIG_PPC_KERNEL_PCREL enabled.
--

commit b4e7d4404702ca69adf00490d083d127f762e2ed
Author: Abhishek Dubey <adubey@linux.ibm.com>

selftest/bpf: Add tailcall verifier selftest for powerpc64

This commit adds a tailcall verifier selftest targeting the powerpc64
architecture. It introduces __arch_powerpc64 JIT regex matches for both
regular function calls and tail calls.

> diff --git a/tools/testing/selftests/bpf/progs/verifier_tailcall_jit.c b/tools/testing/selftests/bpf/progs/verifier_tailcall_jit.c
> index 48fa34d2959f4..09d7e92c84910 100644
> --- a/tools/testing/selftests/bpf/progs/verifier_tailcall_jit.c
> +++ b/tools/testing/selftests/bpf/progs/verifier_tailcall_jit.c
> @@ -91,6 +91,75 @@ __jited("	popq	%rax")
>  __jited("	jmp	{{.*}}")		/* jump to tail call tgt   */
>  __jited("L0:	leave")
>  __jited("	{{(retq|jmp	0x)}}")		/* return or jump to rethunk */
> +__arch_powerpc64
> +/* program entry for main(), regular function prologue */
> +__jited("	nop")
> +__jited("...")                          /* ld 2, 16(13) absent with CONFIG_PPC_KERNEL_PCREL */
> +__jited("	li 9, 0")
> +__jited("	std 9, -8(1)")
> +__jited("	mflr 0")
> +__jited("	std 0, 16(1)")
> +__jited("	stdu 1, {{.*}}(1)")
> +/* load address and call sub() via count register */
> +__jited("	lis 12, {{.*}}")
> +__jited("	sldi 12, 12, 32")
> +__jited("	oris 12, 12, {{.*}}")
> +__jited("	ori 12, 12, {{.*}}")

[Severity: Medium]
Will this strict absolute 64-bit load match fail on Power10 and other
kernels with CONFIG_PPC_KERNEL_PCREL enabled?

It appears that when CONFIG_PPC_KERNEL_PCREL is enabled,
bpf_jit_emit_func_call_rel() checks if the relative offset between the
call site and the target is within 8GB. Since main() and sub() are BPF
programs allocated close to each other in vmalloc space, the offset should
fit within 8GB.

This means the JIT would emit a PC-relative load (pla r12, addr followed
by paddi) instead of the absolute load sequence expected here. Does the test
need a fallback or PCREL-specific wildcard block?

> +__jited("	mtctr 12")
> +__jited("	bctrl")

[ ... ]

> +/* tail call prologue for subprogram */
> +__jited("	ld 10, 0(1)")
> +__jited("	ld 9, -8(10)")
> +__jited("	cmpldi	9, 33")
> +__jited("	bt	{{.*}}, {{.*}}")
> +__jited("	addi 9, 10, -8")
> +__jited("	std 9, -8(1)")
> +__jited("	lis {{.*}}, {{.*}}")
> +__jited("	sldi {{.*}}, {{.*}}, 32")
> +__jited("	oris {{.*}}, {{.*}}, {{.*}}")
> +__jited("	ori {{.*}}, {{.*}}, {{.*}}")

[Severity: Medium]
Can this strict expectation for oris and ori cause test failures depending
on the page size?

The PPC_LI64 macro optimizes 64-bit immediate loads by omitting the ori
instruction if the lowest 16 bits are zero, and oris if bits 16-31 are zero.

Because the test loads the address of the jmp_table map, which is allocated
via vmalloc() and is page-aligned, on PowerPC64 systems with a 64KB page size
the lowest 16 bits will always be zero. This would cause the ori instruction
to be omitted entirely, resulting in a regex mismatch.

> +__jited("	li {{.*}}, 0")
> +__jited("	lwz 9, {{.*}}({{.*}})")

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260623231411.6216-1-adubey@linux.ibm.com?part=6