> diff --git a/tools/testing/selftests/bpf/progs/bpf_misc.h
> b/tools/testing/selftests/bpf/progs/bpf_misc.h
> index 9eeb5b0b63d6..cdc2a3de3054 100644
> --- a/tools/testing/selftests/bpf/progs/bpf_misc.h
> +++ b/tools/testing/selftests/bpf/progs/bpf_misc.h
> @@ -158,6 +158,7 @@
> #define __arch_arm64 __arch("ARM64")
> #define __arch_riscv64 __arch("RISCV64")
> #define __arch_s390x __arch("s390x")
> +#define __arch_powerpc64 __arch("POWERPC64")
> #define __caps_unpriv(caps) __test_tag("test_caps_unpriv="
> EXPAND_QUOTE(caps))
> #define __load_if_JITed() __test_tag("load_mode=jited")
> #define __load_if_no_JITed() __test_tag("load_mode=no_jited")
> diff --git a/tools/testing/selftests/bpf/test_loader.c
> b/tools/testing/selftests/bpf/test_loader.c
> index abdb9e6e3713..d5589355ed9e 100644
> --- a/tools/testing/selftests/bpf/test_loader.c
> +++ b/tools/testing/selftests/bpf/test_loader.c
> @@ -377,6 +377,7 @@ enum arch {
> ARCH_ARM64 = 0x4,
> ARCH_RISCV64 = 0x8,
> ARCH_S390X = 0x10,
> + ARCH_POWERPC64 = 0x20,
> };
>
> static int get_current_arch(void)
> @@ -389,6 +390,8 @@ static int get_current_arch(void)
> return ARCH_RISCV64;
> #elif defined(__s390x__)
> return ARCH_S390X;
> +#elif defined(__powerpc64__)
> + return ARCH_POWERPC64;
> #endif
> return ARCH_UNKNOWN;
> }
> @@ -580,6 +583,8 @@ static int parse_test_spec(struct test_loader *tester,
> arch = ARCH_RISCV64;
> } else if (strcmp(val, "s390x") == 0) {
> arch = ARCH_S390X;
> + } else if (strcmp(val, "POWERPC64") == 0) {
> + arch = ARCH_POWERPC64;
> } else {
> PRINT_FAIL("bad arch spec: '%s'\n", val);
> err = -EINVAL;
This patch looks clean. However, unaddressed review comments from earlier
versions of related patches in the series were identified:
https://lore.kernel.org/bpf/[email protected]
Three issues were raised by [email protected] on Sun, 17 May 2026 about
alignment logic in arch/powerpc/net/bpf_jit_comp.c (from a related commit in
this series):
Issue 1: In bpf_jit_build_fentry_stubs(), the alignment NOP is only emitted
when (fimage && image) is true. During pass 0 sizing, both are NULL, so the
NOP is skipped and proglen is calculated without it.
During final passes 1 and 2, if the NOP is emitted, could this increase the
instruction count beyond proglen and overflow into the exception table or
fixups?
Issue 2: In the same function, the alignment calculation appears flawed:
unsigned long pc = (unsigned long)fimage + CTX_NIA(ctx);
pc += IS_ENABLED(CONFIG_PPC_FTRACE_OUT_OF_LINE) ? 11 : 10;
The comment says "11/10 instructions" but pc is a byte address. Adding 11 or
10 adds bytes instead of the intended 44 or 40 bytes (since PowerPC
instructions are 4 bytes).
Adding 4 bytes to an 8-byte aligned address makes it unaligned. Does this
force the code to emit a NOP when the target address is already aligned?
Issue 3: In bpf_jit_emit_exit_insn(), the code passes NULL for fimage:
} else {
ctx->alt_exit_addr = ctx->idx * 4;
bpf_jit_build_epilogue(image, NULL, ctx);
Because fimage is strictly passed as NULL, the (fimage && image) check will
always evaluate to false. Will this cause the alignment NOP to be
unconditionally skipped for all inline epilogues, leaving their
dummy_tramp_addr fields unaligned?
These comments should be addressed in the related commits of this series.
---
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/25998434343
