kernel/git/stable/linux-stable.git/arch/powerpc, branch linux-rolling-stable

powerpc/configs: enable CONFIG_RAS to fix EDAC support

2026-09-14T11:40:37+00:00

[ Upstream commit 3921cfc2e8155a767235801be88cbd0e4c73508d ] Before commit e3c4ff6d8c94 ("EDAC: Remove EDAC_MM_EDAC") EDAC_MM_EDAC selected RAS, after that commit, EDAC depends on RAS, but nobody enables it. Enable it in the config again. Fixes: e3c4ff6d8c94 ("EDAC: Remove EDAC_MM_EDAC") Signed-off-by: Michael Walle Acked-by: Borislav Petkov (AMD) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260730105546.3658570-1-mwalle@kernel.org Signed-off-by: Sasha Levin

powerpc/irq: Fix missing r2 clobber in PCREL inline assembly

2026-09-14T11:40:12+00:00

[ Upstream commit 00be69070d91d2be978e752bb117a0a4db0e1281 ] In CONFIG_PPC_KERNEL_PCREL mode, r2 is no longer reserved for the TOC pointer and is available as a caller-saved register [0]. Both call_do_irq() and call_do_softirq() use inline assembly to call functions with stack switching, but fail to list r2 in their clobber lists. This causes the compiler to assume r2 is preserved across these calls, leading to register corruption when the called functions (__do_irq and __do_softirq) clobber r2. As a result of this kernel crash during interrupt handling is seen and the kernel fails to boot: BUG: Unable to handle kernel data access on write at 0xc000000404697638 Faulting instruction address: 0xc0000000000181ec Oops: Kernel access of bad area, sig: 11 [#1] NIP [c0000000000181ec] __do_IRQ+0x6c/0xc0 With older GCC, the compiler would conservatively allocate callee-saved registers (like r31) for values spanning function calls, accidentally avoiding the bug: <__do_IRQ>: 00 00 00 60 nop a6 02 08 7c mflr r0 f8 ff e1 fb std r31,-8(r1) f0 ff c1 fb std r30,-16(r1) 2d 03 10 06 pla r31,53297316 ... 3d e8 ff 4b bl c0000000000165ac <__do_irq> 00 00 21 e8 ld r1,0(r1) 28 00 4d e9 ld r10,40(r13) 40 00 21 38 addi r1,r1,64 2a f9 aa 7f stdx r29,r10,r31 With newer GCC 14, the compiler uses r2 for such values, exposing the missing clobber specification: <__do_IRQ>: 00 00 00 60 nop a6 02 08 7c mflr r0 f0 ff c1 fb std r30,-16(r1) f8 ff e1 fb std r31,-8(r1) 29 02 10 06 pla r2,36252592 # c0000000022aadc0 <__irq_regs> ... 85 dc ff 4b bl c000000000015ee0 <__do_irq> 00 00 21 e8 ld r1,0(r1) 28 00 2d e9 ld r9,40(r13) 30 00 21 38 addi r1,r1,48 2a 11 c9 7f stdx r30,r9,r2 Fix this by adding r2 to the clobber list for both call_do_irq() and call_do_softirq() when CONFIG_PPC_KERNEL_PCREL is enabled. [0]: https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg313226.html Fixes: 7e3a68be42e1 ("powerpc/64: vmlinux support building with PCREL addresing") Signed-off-by: Saket Kumar Bhaskar Reviewed-by: Christophe Leroy (CS GROUP) Reviewed-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/10fc2cda485cd22e209a31d786bed1984bdf3982.1785732393.git.skb99@linux.ibm.com Signed-off-by: Sasha Levin

powerpc64/bpf: Fix build break for arch_bpf_timed_may_goto

2026-09-14T11:40:12+00:00

[ Upstream commit e1e5e682511eda648aa91372542cc8f665ad0bff ] With CONFIG_PPC_KERNEL_PCREL enabled, calling bpf_check_timed_may_goto() using a bl instruction results in a link-time failure: arch/powerpc/net/bpf_timed_may_goto.o: in function `arch_bpf_timed_may_goto': (.text+0x28): call to `bpf_check_timed_may_goto' lacks nop, can't restore toc Use CFUNC() macro instead of direct 'bl' to properly annotate the call to bpf_check_timed_may_goto(). On PCREL builds, CFUNC() expands to 'bl name@notoc', informing the linker that TOC restoration is not needed, avoiding the "lacks nop, can't restore toc" linker error. Fixes: b55b6b9ad76c ("powerpc64/bpf: Add powerpc64 JIT support for timed may_goto") Signed-off-by: Saket Kumar Bhaskar Reviewed-by: Christophe Leroy (CS GROUP) Reviewed-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/f75e5aa911afb984a94c0e85d58b1be5fb428548.1785387718.git.skb99@linux.ibm.com Signed-off-by: Sasha Levin

powerpc64/bpf: Fix build break in bpf_jit_emit_func_call_rel()

2026-09-14T11:40:12+00:00

[ Upstream commit e8ee988c0087248324dbd3da486d22045e4a4079 ] With CONFIG_PPC_KERNEL_PCREL enabled, build breaks with below error: CC mm/dmapool.o CC fs/readdir.o arch/powerpc/net/bpf_jit_comp64.c: In function 'bpf_jit_emit_func_call_rel': arch/powerpc/net/bpf_jit_comp64.c:475:13: error: unused variable 'ret' [-Werror=unused-variable] 475 | int ret; | ^~~ Commit b55b6b9ad76c ("powerpc64/bpf: Add powerpc64 JIT support for timed may_goto") introduced "ret" at function scope, but it is only used within its respective conditional blocks. Same holds true for reladdr. Move both variable declarations to the scopes where they are actually used: "reladdr" to the CONFIG_PPC_KERNEL_PCREL block and "ret" to the non-PCREL else block. Fixes: b55b6b9ad76c ("powerpc64/bpf: Add powerpc64 JIT support for timed may_goto") Signed-off-by: Saket Kumar Bhaskar Reviewed-by: Hari Bathini Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/e8e582fb425db165a72f00e3337cdf4c6ae383ad.1785387718.git.skb99@linux.ibm.com Signed-off-by: Sasha Levin

powerpc/syscall: Fix syscall skip handling for seccomp and ptrace

2026-09-14T11:40:12+00:00

[ Upstream commit 69cb2be898be6d5826cacd1a628f6945a24480b6 ] After enabling GENERIC_ENTRY on PowerPC, syscall_enter_from_user_mode() returns -1 as a sentinel to signal that seccomp or ptrace has intercepted the syscall and already set a return value via syscall_set_return_value(). system_call_exception() was not handling this sentinel, and since -1UL is >= NR_syscalls, the code fell into the out-of-range path and returned -ENOSYS, overwriting the errno already placed in regs->gpr[3]. The naive fix of checking r0 == -1L before the NR_syscalls bounds check is ambiguous: a user legitimately calling syscall(-1) also produces r0 == -1L, and a tracer intercepting such a call would have its injected return value silently discarded. Fix this by introducing a thread flag that is set whenever syscall_set_return_value() explicitly updates the return value. In system_call_exception(), check and clear this flag before dispatching the syscall, and return the preset value directly when it is present. This ensures that an explicitly supplied return value always suppresses syscall execution, regardless of the syscall number. This handles all seccomp actions correctly: - SECCOMP_RET_ERRNO, SECCOMP_RET_TRACE (no tracer), SECCOMP_RET_USER_NOTIF: all call syscall_set_return_value(), flag is set, injected value returned. - SECCOMP_RET_TRAP, SECCOMP_RET_KILL: call syscall_rollback() and deliver a signal; flag is not set, but the process is dying so the return value is irrelevant. The fix covers both ppc32 and ppc64 with no #ifdefs. Fixes: bee25f97ad24 ("powerpc: Enable GENERIC_ENTRY feature") Reported-by: Michal Suchánek Closes: https://lore.kernel.org/all/ajpp-_XnbF3UTM_E@kunlun.suse.cz/ Tested-by: Michal Suchánek Reviewed-by: Michal Suchánek Signed-off-by: Mukesh Kumar Chaurasiya (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260731081521.1852133-1-mkchauras@gmail.com Signed-off-by: Sasha Levin

powerpc/smp: add NULL guard for cause_ipi in smp_muxed_ipi_message_pass

2026-09-14T11:40:12+00:00

[ Upstream commit 5aabc192702defb8950e7c81b05c3f4ca8ee43ec ] smp_muxed_ipi_message_pass() calls smp_ops->cause_ipi() without checking whether it has been set. On platforms using muxed IPI (e.g. powernv/pseries), smp_ops->cause_ipi is initialized to NULL in the static smp_ops and only assigned during the platform smp_probe() handler. If the IPI subsystem fails to initialize -- for example when xive_init_ipis() fails and xive_smp_probe() returns an error -- the probe handler returns early and cause_ipi is never set. Any subsequent IPI send (e.g. arch_smp_send_reschedule()) would dereference the NULL pointer. Add a NULL check to avoid the crash in that situation. Fixes: 23d72bfd8f9f ("powerpc: Consolidate ipi message mux and demux") Signed-off-by: Gou Hao Reviewed-by: jiazhenyuan Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260727104215.184786-6-gouhao@uniontech.com Signed-off-by: Sasha Levin

powerpc/xive: propagate IPI init errors to prevent use-after-free

2026-09-14T11:40:12+00:00

[ Upstream commit 411a3c016e7a95f5fa105a0587e07d0647a77727 ] When xive_init_ipis() fails (e.g. irq_domain_alloc_irqs() fails), the error path frees the global xive_ipis array. However, xive_smp_probe() previously ignored this failure and proceeded to call xive_setup_cpu_ipi(), which dereferences the already-freed xive_ipis pointer -- a use-after-free. Now that xive_smp_probe() returns int (previous patch), propagate the error from xive_init_ipis() and xive_setup_cpu_ipi() through xive_smp_probe(). Check the return value in both pnv_smp_probe() and pSeries_smp_probe() so that IPI setup is aborted cleanly on failure, avoiding the use-after-free. Fixes: 243e25112d06 ("powerpc/xive: Native exploitation of the XIVE interrupt controller") Fixes: cbc06f051c52 ("powerpc/xive: Do not skip CPU-less nodes when creating the IPIs") Signed-off-by: Gou Hao Reviewed-by: Wentao Guan Reviewed-by: jiazhenyuan Reviewed-by: Cédric Le Goater Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260727104215.184786-4-gouhao@uniontech.com Signed-off-by: Sasha Levin

powerpc/xive: add error return value to xive_smp_probe()

2026-09-14T11:40:12+00:00

[ Upstream commit ab5ae5dceb86614f6c9e7488f91b652000edfdc5 ] xive_smp_probe() calls xive_init_ipis() which can fail, but its return value is currently ignored. Change xive_smp_probe() to return int so that errors can be propagated to callers. This is a preparatory patch for the next one. No functional change yet; the return value is always 0 at this point. Signed-off-by: Gou Hao Reviewed-by: Wentao Guan Reviewed-by: jiazhenyuan Reviewed-by: Cédric Le Goater Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260727104215.184786-3-gouhao@uniontech.com Stable-dep-of: 411a3c016e7a ("powerpc/xive: propagate IPI init errors to prevent use-after-free") Signed-off-by: Sasha Levin

powerpc/xive: make xive IPI allocation NULL-safe

2026-09-14T11:40:12+00:00

[ Upstream commit f068fca7e8b7014014296b0e458ba9c5aa77f954 ] __GFP_NOFAIL should not be used in new code [1]. xive_init_ipis() allocates the xive_ipis array with __GFP_NOFAIL, which makes the subsequent NULL check unreachable dead code. Remove __GFP_NOFAIL so the allocation can fail, and make all xive_ipis access paths NULL-safe: - Return XIVE_BAD_IRQ from xive_ipi_cpu_to_irq() when xive_ipis is NULL. - Set xive_ipis to NULL after kfree() in the error path to prevent use-after-free. - Guard xive_setup_cpu_ipi() and xive_cleanup_cpu_ipi() against xive_ipi_irq == XIVE_BAD_IRQ to avoid dereferencing an uninitialized or already-freed xive_ipis array. No functional change when allocation succeeds. Link: https://lore.kernel.org/all/20260725202632.dcb325658896a470df91cf57@linux-foundation.org/ [1] Fixes: 7dcc37b3eff9 ("powerpc/xive: Map one IPI interrupt per node") Signed-off-by: Gou Hao Suggested-by: Andrew Morton Suggested-by: Cédric Le Goater Suggested-by: Mukesh Kumar Chaurasiya (IBM) Reviewed-by: Wentao Guan Reviewed-by: jiazhenyuan Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Reviewed-by: Cédric Le Goater Reviewed-by: Andrew Morton Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260727104215.184786-2-gouhao@uniontech.com Signed-off-by: Sasha Levin

powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr()

2026-09-14T11:40:02+00:00

[ Upstream commit 4cc4b586007fbbf8edba4f1d0849e9a06b0cf6c3 ] In get_crash_memory_ranges(), if crash_exclude_mem_range() failed after realloc_mem_ranges() has successfully allocated the cmem memory, it just returns an error but leaves cmem pointing to the allocated memory, nor is it freed in the caller update_crash_elfcorehdr(), which cause a memory leak, goto out to free the cmem. Fixes: 849599b702ef ("powerpc/crash: add crash memory hotplug support") Reviewed-by: Sourabh Jain Signed-off-by: Jinjie Ruan Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260729012948.2797865-2-ruanjinjie@huawei.com Signed-off-by: Sasha Levin