> diff --git a/tools/testing/selftests/bpf/jit_disasm_helpers.c
> b/tools/testing/selftests/bpf/jit_disasm_helpers.c
> index 364c557c5115..21e3e3e68c14 100644
> --- a/tools/testing/selftests/bpf/jit_disasm_helpers.c
> +++ b/tools/testing/selftests/bpf/jit_disasm_helpers.c
[ ... ]
> @@ -216,9 +218,28 @@ int get_jited_program_text(int fd, char *text, size_t
> text_sz)
> if (!ASSERT_OK(err, "bpf_prog_get_info_by_fd #2"))
> goto out;
>
> + /*
> + * last 8 bytes contains dummy_trampoline address in JIT
> + * output on 64-bit and last 4 bytes on 32-bit powerpc,
> + * which can't disassemble to a valid instruction.
> + */
> + triple = LLVMGetDefaultTargetTriple();
> + if (triple) {
> + if (strstr(triple, "powerpc")) {
> + if (IS_ENABLED(CONFIG_PPC64))
> + trunc_len = 8;
> + else
> + trunc_len = 4;
> + }
> + LLVMDisposeMessage(triple);
> + }
Can IS_ENABLED(CONFIG_PPC64) ever be true in this file?
This is a userspace selftest (tools/testing/selftests/bpf/jit_disasm_helpers.c).
IS_ENABLED here resolves to tools/include/linux/kconfig.h:
#define IS_ENABLED(option) __or(IS_BUILTIN(option), IS_MODULE(option))
which ultimately tests __is_defined(CONFIG_PPC64), i.e. whether CONFIG_PPC64
is a defined preprocessor macro.
The kernel proper makes CONFIG_* macros visible by force-including
include/generated/autoconf.h via the build flags. The selftests/bpf build
does not do that: tools/testing/selftests/bpf/Makefile only adds an include
search path and -DHAVE_GENHDR, with no -include autoconf.h, and the include
chain for this file never pulls in generated/autoconf.h.
So CONFIG_PPC64 is undefined and IS_ENABLED(CONFIG_PPC64) is 0 on every
build, including ppc64/ppc64le. trunc_len then always becomes 4.
On 64-bit powerpc the JITed stub appends an 8-byte dummy trampoline address,
but only 4 bytes get truncated. The remaining 4 bytes are still handed to the
disassembler, which can decode them into a seemingly valid instruction, which
is the failure this change is meant to fix. Would a runtime check on the
triple, for example strstr(triple, "powerpc64"), be needed to distinguish
64-bit from 32-bit here, since the 8-vs-4 selection is otherwise compile-time?
> +
> for (pc = 0, i = 0; i < jited_funcs; ++i) {
> fprintf(text_out, "func #%d:\n", i);
> - disasm_one_func(text_out, image + pc, func_lens[i]);
> + /* Disabled JIT have zero func_lens, hence underflow */
> + __u32 disasm_len = func_lens[i] > trunc_len ?
> + func_lens[i] - trunc_len : 0;
> + disasm_one_func(text_out, image + pc, disasm_len);
> fprintf(text_out, "\n");
> pc += func_lens[i];
> }
The commit message describes fixing a powerpc JIT disassembly failure caused
by the dummy trampoline address emitted at the tail of the long_branch stub.
That trailing field was introduced by commit d243b62b7bd3 ("powerpc64/bpf:
Add support for bpf trampolines"). The two sibling commits in this series
both carry that Fixes: tag, but this selftest-side commit does not.
Should this include:
Fixes: d243b62b7bd3 ("powerpc64/bpf: Add support for bpf trampolines")
---
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/26605473656
