linux/arch/powerpc/net, branch master

bpf: Pass bpf_verifier_env to JIT

2026-04-16T14:03:40Z

Pass bpf_verifier_env to bpf_int_jit_compile(). The follow-up patch will use env->insn_aux_data in the JIT stage to detect indirect jump targets. Since bpf_prog_select_runtime() can be called by cbpf and lib/test_bpf.c code without verifier, introduce helper __bpf_prog_select_runtime() to accept the env parameter. Remove the call to bpf_prog_select_runtime() in bpf_prog_load(), and switch to call __bpf_prog_select_runtime() in the verifier, with env variable passed. The original bpf_prog_select_runtime() is preserved for cbpf and lib/test_bpf.c, where env is NULL. Now all constants blinding calls are moved into the verifier, except the cbpf and lib/test_bpf.c cases. The instructions arrays are adjusted by bpf_patch_insn_data() function for normal cases, so there is no need to call adjust_insn_arrays() in bpf_jit_blind_constants(). Remove it. Reviewed-by: Anton Protopopov # v8 Reviewed-by: Emil Tsalapatis # v12 Acked-by: Hengqi Chen # v14 Signed-off-by: Xu Kuohai Link: https://lore.kernel.org/r/20260416064341.151802-3-xukuohai@huaweicloud.com Signed-off-by: Alexei Starovoitov

bpf: Move constants blinding out of arch-specific JITs

2026-04-16T14:03:40Z

During the JIT stage, constants blinding rewrites instructions but only rewrites the private instruction copy of the JITed subprog, leaving the global env->prog->insnsi and env->insn_aux_data untouched. This causes a mismatch between subprog instructions and the global state, making it difficult to use the global data in the JIT. To avoid this mismatch, and given that all arch-specific JITs already support constants blinding, move it to the generic verifier code, and switch to rewrite the global env->prog->insnsi with the global states adjusted, as other rewrites in the verifier do. This removes the constants blinding calls in each JIT, which are largely duplicated code across architectures. Since constants blinding is only required for JIT, and there are two JIT entry functions, jit_subprogs() for BPF programs with multiple subprogs and bpf_prog_select_runtime() for programs with no subprogs, move the constants blinding invocation into these two functions. In the verifier path, bpf_patch_insn_data() is used to keep global verifier auxiliary data in sync with patched instructions. A key question is whether this global auxiliary data should be restored on the failure path. Besides instructions, bpf_patch_insn_data() adjusts: - prog->aux->poke_tab - env->insn_array_maps - env->subprog_info - env->insn_aux_data For prog->aux->poke_tab, it is only used by JIT or only meaningful after JIT succeeds, so it does not need to be restored on the failure path. For env->insn_array_maps, when JIT fails, programs using insn arrays are rejected by bpf_insn_array_ready() due to missing JIT addresses. Hence, env->insn_array_maps is only meaningful for JIT and does not need to be restored. For subprog_info, if jit_subprogs fails and CONFIG_BPF_JIT_ALWAYS_ON is not enabled, kernel falls back to interpreter. In this case, env->subprog_info is used to determine subprogram stack depth. So it must be restored on failure. For env->insn_aux_data, it is freed by clear_insn_aux_data() at the end of bpf_check(). Before freeing, clear_insn_aux_data() loops over env->insn_aux_data to release jump targets recorded in it. The loop uses env->prog->len as the array length, but this length no longer matches the actual size of the adjusted env->insn_aux_data array after constants blinding. To address it, a simple approach is to keep insn_aux_data as adjusted after failure, since it will be freed shortly, and record its actual size for the loop in clear_insn_aux_data(). But since clear_insn_aux_data() uses the same index to loop over both env->prog->insnsi and env->insn_aux_data, this approach results in incorrect index for the insnsi array. So an alternative approach is adopted: clone the original env->insn_aux_data before blinding and restore it after failure, similar to env->prog. For classic BPF programs, constants blinding works as before since it is still invoked from bpf_prog_select_runtime(). Reviewed-by: Anton Protopopov # v8 Reviewed-by: Hari Bathini # powerpc jit Reviewed-by: Pu Lehui # riscv jit Acked-by: Hengqi Chen # loongarch jit Signed-off-by: Xu Kuohai Link: https://lore.kernel.org/r/20260416064341.151802-2-xukuohai@huaweicloud.com Signed-off-by: Alexei Starovoitov

powerpc32/bpf: fix loading fsession func metadata using PPC_LI32

2026-04-08T04:32:04Z

PPC_RAW_LI32 is not a valid macro in the PowerPC BPF JIT. Use PPC_LI32, which correctly handles immediate loads for large values. Fixes the build error introduced when adding fsession support on ppc32. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202604040212.jIxEd2DW-lkp@intel.com/ Fixes: 92258b5bf1ec ("powerpc32/bpf: Add fsession support") Signed-off-by: Abhishek Dubey Reviewed-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260408055301.232745-1-adubey@linux.ibm.com

powerpc64/bpf: Add support for indirect jump

2026-04-03T08:44:25Z

Add support for a new instruction BPF_JMP|BPF_X|BPF_JA, SRC=0, DST=Rx, off=0, imm=0 which does an indirect jump to a location stored in Rx. The register Rx should have type PTR_TO_INSN. This new type ensures that the Rx register contains a value (or a range of values) loaded from a correct jump table – map of type instruction array. Support indirect jump to all registers in powerpc64 JIT using the ctr register. Move Rx content to ctr register, then invoke bctr instruction to branch to address stored in ctr register. Skip save and restore of TOC as the jump is always within the program context. Signed-off-by: Abhishek Dubey Acked-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260401152133.42544-4-adubey@linux.ibm.com

powerpc/bpf: Add support for instruction array

2026-04-03T08:44:25Z

On loading the BPF program, the verifier might adjust/omit some instructions. The adjusted instruction offset is accounted in the map containing original instruction -> xlated mapping. This patch add ppc64 JIT support to additionally build the xlated->jitted mapping for every instruction present in instruction array. This change is needed to enable support for indirect jumps, added in a subsequent patch. Invoke bpf_prog_update_insn_ptrs() with offset pair of xlated_offset and jited_offset. The offset mapping is already available, which is being used for bpf_prog_fill_jited_linfo() and can be directly used for bpf_prog_update_insn_ptrs() as well. Additional details present at: commit b4ce5923e780 ("bpf, x86: add new map type: instructions array") Signed-off-by: Abhishek Dubey Acked-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260401152133.42544-2-adubey@linux.ibm.com

powerpc32/bpf: Add fsession support

2026-04-03T08:40:48Z

Extend JIT support of fsession in powerpc64 trampoline, since ppc64 and ppc32 shares common trampoline implementation. Arch specific helpers handle 64-bit data copy using 32 bit regs. Need to validate fsession support along with trampoline support. Signed-off-by: Abhishek Dubey Acked-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260401141043.41513-2-adubey@linux.ibm.com

powerpc64/bpf: Implement fsession support

2026-04-03T08:40:48Z

Implement JIT support for fsession in powerpc64 trampoline. The trampoline stack now accommodate session cookies and function metadata in place of function argument. fentry/fexit programs consume corresponding function metadata. This mirrors existing x86 behavior and enable session cookies on powerpc64. # ./test_progs -t fsession #135/1 fsession_test/fsession_test:OK #135/2 fsession_test/fsession_reattach:OK #135/3 fsession_test/fsession_cookie:OK #135 fsession_test:OK Summary: 1/3 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Abhishek Dubey Tested-by: Venkat Rao Bagalkote Acked-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260401141043.41513-1-adubey@linux.ibm.com

powerpc64/bpf: Implement JIT support for private stack

2026-04-03T08:39:43Z

Provision the private stack as a per-CPU allocation during bpf_int_jit_compile(). Align the stack to 16 bytes and place guard regions at both ends to detect runtime stack overflow and underflow. Round the private stack size up to the nearest 16-byte boundary. Make each guard region 16 bytes to preserve the required overall 16-byte alignment. When private stack is set, skip bpf stack size accounting in kernel stack. There is no stack pointer in powerpc. Stack referencing during JIT is done using frame pointer. Frame pointer calculation goes like: BPF frame pointer = Priv stack allocation start address + Overflow guard + Actual stack size defined by verifier Memory layout: High Addr +--------------------------------------------------+ | | | 16 bytes Underflow guard (0xEB9F12345678eb9fULL) | | | BPF FP -> +--------------------------------------------------+ | | | Private stack - determined by verifier | | 16-bytes aligned | | | +--------------------------------------------------+ | | Lower Addr | 16 byte Overflow guard (0xEB9F12345678eb9fULL) | | | Priv stack alloc ->+--------------------------------------------------+ start Update BPF_REG_FP to point to the calculated offset within the allocated private stack buffer. Now, BPF stack usage reference in the allocated private stack. Signed-off-by: Abhishek Dubey Tested-by: Venkat Rao Bagalkote Acked-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260401103215.104438-1-adubey@linux.ibm.com

powerpc64/bpf: fix kfunc call support

2026-03-07T10:32:26Z

Commit 61688a82e047 ("powerpc/bpf: enable kfunc call") inadvertently enabled kfunc call support for 32-bit powerpc but that support will not be possible until ABI mismatch between 32-bit powerpc and eBPF is handled in 32-bit powerpc JIT code. Till then, advertise support only for 64-bit powerpc. Also, in powerpc ABI, caller needs to extend the arguments properly based on signedness. The JIT code is responsible for handling this explicitly for kfunc calls as verifier can't handle this for each architecture-specific ABI needs. But this was not taken care of while kfunc call support was enabled for powerpc. Fix it by handling this with bpf_jit_find_kfunc_model() and using zero_extend() & sign_extend() helper functions. Fixes: 61688a82e047 ("powerpc/bpf: enable kfunc call") Cc: stable@vger.kernel.org Signed-off-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260303181031.390073-7-hbathini@linux.ibm.com

powerpc64/bpf: fix handling of BPF stack in exception callback

2026-03-07T10:32:26Z

Exception callback reuses the stack frame of exception boundary. When exception boundary and exception callback programs have different BPF stack depth, the current stack unwind in exception callback will fail. Adjust the stack frame size of exception callback, in its prologue, if its BPF stack depth is different from that of exception boundary. Reported-by: bot+bpf-ci@kernel.org Closes: https://lore.kernel.org/bpf/2a310e86a59eb4c44c3ac9e5647814469d9c955580c9c0f1b3d9ca4a44717a34@mail.kernel.org/ Fixes: 11d45eee9f42 ("powerpc64/bpf: Additional NVR handling for bpf_throw") Signed-off-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260303181031.390073-6-hbathini@linux.ibm.com