> commit 6ef500644d23a07941d6ec45def92b9391c03a10 > Author: Abhishek Dubey <[email protected]> > Date: Mon Sep 28 10:43:53 2026 +0530 > > powerpc/bpf: fix alignment of long branch trampoline address > > Ensure the dummy trampoline address field present between the OOL stub > and the long branch stub is 4/8-byte aligned, for memory compatibility > when content loaded to a register. > > Reported-by: Hari Bathini <[email protected]> > Fixes: d243b62b7bd3 ("powerpc64/bpf: Add support for bpf trampolines") > Cc: [email protected] > Signed-off-by: Abhishek Dubey <[email protected]> > Signed-off-by: Saket Kumar Bhaskar <[email protected]> > Tested-by: Yeswanth Krishna Tellakula <[email protected]> > Tested-by: R Nageswara Sastry <[email protected]> > Reviewed-by: Hari Bathini <[email protected]>
This isn't a bug, but could the changelog say what fails when the slot is only 4-byte aligned, and briefly explain why sizing with an unconditional NOP and then conditionally dropping it in the final pass is safe? The load-bearing rationale seems to be missing. From the code, bpf_jit_binary_pack_alloc() only guarantees 4-byte alignment of the final image, so the SZL-sized slot read by the long branch stub and rewritten by patch_ulong() from bpf_arch_text_poke() may be only 4-byte aligned on ppc64, where an 8-byte access is then not guaranteed to be single-copy atomic against a concurrent patch. The non-obvious part of the fix is that the NOP is emitted unconditionally in the sizing pass when image is NULL and conditionally on the final fimage address in the codegen passes, so the allocated buffer may have 4 spare bytes while jited_len reflects the actual size. The phrase "4/8-byte aligned" also blurs that only the 64-bit case needs the NOP since SZL is 4 on ppc32. --- 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/36381917401
