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

Merge tag 'powerpc-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux

2026-09-08T14:59:12+00:00

Pull powerpc fixes from Madhavan Srinivasan: - Clear TIF_SYSCALL_RET before syscall error return - Don't drop _TIF_RESTOREALL on syscall restart - Do not restore KUAP in arch_exit_to_user_mode_prepare() - pci-ioda: Fix the stale irq chip reference - Use inclusive range checks in add_usable_mem() and excluded memory - Fix irq_soft_mask corruption on replayed interrupt exit - MAINTAINERS: powerpc: Add Ritesh and Shrikanth - Misc fixes and cleanups Thanks to Amit Machhiwal, Christophe Leroy (CS GROUP), Gautam Menghani, Harsh Prateek Bora, Jiangshan Yi, Mukesh Kumar Chaurasiya (IBM), Ritesh Harjani (IBM), Shivaprasad G Bhat, Shrikanth Hegde, Sourabh Jain, Tasmiya Nalatwad, Thorsten Blum, and Venkat Rao Bagalkote. * tag 'powerpc-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: MAINTAINERS: powerpc: Add Ritesh and Shrikanth powerpc/ps3: Fix repository.c build failure powerpc/entry: Fix irq_soft_mask corruption on replayed interrupt exit powerpc/pseries/pci: Fix misleading VF limit error message powerpc/kexec_file: Use inclusive range checks for excluded memory powerpc/kexec: Simplify kdump_extra_elfcorehdr_size() powerpc/kexec_file: Use inclusive range checks in add_usable_mem() powerpc/rtas_pci: No hotplug on permanently removed device on pSeries powerpc/eeh: Fix recursive locking on devices without EEH sensitive driver powerpc: pci-ioda: Fix the stale irq chip reference powerpc: Do not restore KUAP in arch_exit_to_user_mode_prepare() powerpc: Don't drop _TIF_RESTOREALL on syscall restart powerpc/entry: Clear TIF_SYSCALL_RET before syscall error return

powerpc/ps3: Fix repository.c build failure

2026-09-07T04:38:46+00:00

GCC fails to build ps3_defconfig with the following errors: arch/powerpc/platforms/ps3/repository.c: In function ‘make_first_field.constprop’: arch/powerpc/platforms/ps3/repository.c:78:9: error: ‘strnlen’ specified bound 8 exceeds source size 3 [-Werror=stringop-overread] 78 | memcpy((char *)&n, text, strnlen(text, sizeof(n))); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/platforms/ps3/repository.c: In function ‘make_first_field.constprop’: arch/powerpc/platforms/ps3/repository.c:78:9: error: ‘strnlen’ specified bound 8 exceeds source size 4 [-Werror=stringop-overread] 78 | memcpy((char *)&n, text, strnlen(text, sizeof(n))); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The current use of strnlen(text, sizeof(n)) triggers -Wstringop-overread when text is a short string literal that is smaller than sizeof(n), such as "bi" or "bus". Use strlen(text) instead and clamp the copy length to sizeof(n) before memcpy(). Drop the redundant char * cast while at it. Fixes: f94a84a09148 ("powerpc/ps3: refactor strncpy usage") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260703165834.137242-2-thorsten.blum@linux.dev

powerpc/entry: Fix irq_soft_mask corruption on replayed interrupt exit

2026-09-05T12:09:36+00:00

When __replay_soft_interrupts() replays a pending interrupt (e.g. PACA_IRQ_DEC -> timer_interrupt), it calls the handler directly with a synthetic pt_regs. The DEFINE_INTERRUPT_HANDLER_ASYNC wrapper around each handler calls arch_interrupt_async_exit_prepare() on the way out, which calls arch_interrupt_exit_prepare() -> local_irq_disable() -> arch_local_irq_disable(), which does: irq_soft_mask_set(IRQS_DISABLED) /* 0x1 */ This unconditionally overwrites irq_soft_mask with IRQS_DISABLED (0x1), stripping the IRQS_PMI_DISABLED (0x2) bit. The result is that irq_soft_mask is 0x1 instead of IRQS_ALL_DISABLED (0x3) when the handler returns to __replay_soft_interrupts(). For a normally-taken interrupt this is harmless: the next interrupt always enters through arch_interrupt_enter_prepare() which unconditionally sets irq_soft_mask to IRQS_ALL_DISABLED. But during replay, next_interrupt() is called directly between replayed handlers without going back through arch_interrupt_enter_prepare(), so the stripped bit is never restored. next_interrupt() then fires a WARNING: WARNING: arch/powerpc/kernel/irq_64.c:75 WARN_ON(irq_soft_mask_return() != IRQS_ALL_DISABLED) The warning was observed early in boot on a POWER10 pseries guest during kmem_cache_init_late(), where a spinlock release triggers interrupt replay that processes a pending timer interrupt. Debugger state confirming the bug: Before timer_interrupt(®s): irq_soft_mask = 0x3 (IRQS_ALL_DISABLED) correct irq_happened = 0x41 (HARD_DIS|REPLAYING) correct After timer_interrupt(®s) returns: irq_soft_mask = 0x1 (IRQS_DISABLED) WRONG - PMI bit stripped irq_happened = 0x41 unchanged The fix is to replace local_irq_disable() with hard_irq_disable(). hard_irq_disable() is the right primitive here for two reasons: 1. On PPC64 (hw_irq.h:301) it calls irq_soft_mask_set_return(IRQS_ALL_DISABLED), setting the soft mask to 0x3 (both IRQS_DISABLED and IRQS_PMI_DISABLED), which preserves the PMI bit and fixes the WARNING. The additional work it does (__hard_irq_disable(), PACA_IRQ_HARD_DIS |=) is redundant but safe since both are already set at this point in the exit path; the trace_hardirqs_off() inside is guarded by if (!arch_irqs_disabled_flags(flags)) so it will not double-fire. 2. On PPC32 (hw_irq.h:467) hard_irq_disable() maps to arch_local_irq_disable() -> __hard_irq_disable(), which clears MSR[EE] in hardware. This is exactly correct: PPC32 has no soft-mask PACA mechanism, so the hardware disable is the right way to satisfy irqentry_exit()'s requirement. This also fixes a build error on PPC32 where irq_soft_mask_set() is only defined under CONFIG_PPC64: arch/powerpc/include/asm/entry-common.h:273: error: implicit declaration of function 'irq_soft_mask_set' Using hard_irq_disable() requires no #ifdef and is consistent with how the rest of the entry code (e.g. entry-common.h:463) handles the same PPC32/PPC64 split. Fixes: 334f3f6d7a16 ("powerpc/entry: Disable interrupts before irqentry_exit") Reported-by: Venkat Rao Bagalkote Closes: https://lore.kernel.org/all/6f9bfb0f-b14c-468e-bb9f-c157d120d0dc@linux.ibm.com/ Tested-by: Venkat Rao Bagalkote Reviewed-by: Shrikanth Hegde Signed-off-by: Mukesh Kumar Chaurasiya (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260904090858.128563-1-mkchauras@gmail.com

powerpc/pseries/pci: Fix misleading VF limit error message

2026-09-05T05:41:40+00:00

When the number of requested VFs exceeds MAX_VFS_FOR_MAP_PE, the message prints that limit but labels it "Configurable VFs". Report the configurable VF limit and the PE mapping limit with separate error messages. Suggested-by: Christophe Leroy Signed-off-by: Jiangshan Yi Reviewed-by: Christophe Leroy [Maddy: Fixed Christophe's reviewed by tag] Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260813063731.399598-1-yijiangshan@kylinos.cn

powerpc/kexec_file: Use inclusive range checks for excluded memory

2026-09-05T05:41:40+00:00

arch_check_excluded_range() checks if a kexec segment overlaps an excluded memory range. Both ranges use inclusive end addresses, but the overlap check uses exclusive comparisons. This skips ranges with start == ->ranges[i].end or end == ->ranges[i].start. Use inclusive comparisons instead. Fixes: 6e5250eaa665 ("powerpc/crash: use generic APIs to locate memory hole for kdump") Signed-off-by: Thorsten Blum Reviewed-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260810145827.157972-3-thorsten.blum@linux.dev

powerpc/kexec: Simplify kdump_extra_elfcorehdr_size()

2026-09-05T05:41:40+00:00

Return the size directly and drop the extra_sz variable to simplify kdump_extra_elfcorehdr_size(). The two warning paths now fall through to the existing return 0 at the end of the function. Signed-off-by: Thorsten Blum Reviewed-by: Christophe Leroy (CS GROUP) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260730131940.597739-2-thorsten.blum@linux.dev

powerpc/kexec_file: Use inclusive range checks in add_usable_mem()

2026-09-05T05:41:39+00:00

add_usable_mem() adds usable memory ranges for the kdump kernel. The ranges are inclusive, but the partial overlap check uses exclusive comparisons. This skips ranges with base == loc_end or end == loc_base. Use inclusive comparisons instead. Fixes: 7c64e21a1c5a ("powerpc/kexec_file: Restrict memory usage of kdump kernel") Signed-off-by: Thorsten Blum Reviewed-by: Sourabh Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260809162403.18142-2-thorsten.blum@linux.dev

powerpc/rtas_pci: No hotplug on permanently removed device on pSeries

2026-09-05T05:41:39+00:00

The eeh_driver disables and offlines the PE permanently when it exceeds the freeze count beyond eeh_max_freeze within the last hour. The PE is only offline, so the device tree entries, eeh device references are all intact till the real unplug of the device from the guest/host takes place. On pSeries, with a new hotplug of any PCI device, the drmgr initiates a system-wide PCI rescan, which finds devices offlined by the eeh_driver and there will be attempts to bring them online. This leads to recurring EEHs either at the config read time itself or a bit later depending on the type of the problem. For PowerNV, the commit d2b0f6f77ee5 ("powerpc/eeh: No hotplug on permanently removed dev") introduced the EEH_DEV_REMOVED flag to prevent such inadvertent rescans on hierarchical toplogies relavent in Baremetal setups. For pSeries, such topologies don't really make sense as the devices are either part of the same PE OR exposed as independent devices on multiple virtual PHBs. However, the inadvertent rescans are still a possibility with either hotplug of a new device or otherwise with manual system-wide pci bus rescan attempts. So the patch checks for EEH_DEV_REMOVED before allowing config space access just like PowerNV, making the PCI core omit the PE, and thus preventing subsequent EEH recurances. The patch is tested on PowerVM and KVM machines with single and multi-function devices, and on the devices behind a switch. The unplug of the affected devices post EEH removal is also working fine as expected. Signed-off-by: Shivaprasad G Bhat Reported-by: Tasmiya Nalatwad Tested-by: Tasmiya Nalatwad Reviewed-by: Harsh Prateek Bora References: d2b0f6f77ee5 ("powerpc/eeh: No hotplug on permanently removed dev") Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/178246517230.1267.12206176311111155505.stgit@linux.ibm.com

powerpc/eeh: Fix recursive locking on devices without EEH sensitive driver

2026-09-05T05:41:39+00:00

The commit 1010b4c012b0 ("powerpc/eeh: Make EEH driver device hotplug safe") refactored the EEH code such that the pci_rescan_remove_lock is held at the beginning of eeh_handle_normal_event() and the eeh_reset_device() is called with that lock being held. Looks like the commit missed to remove the existing lock/unlock inside eeh_rmv_device() which is no longer necessary. This is causing the eehd to hang on the lock which it actually holds when that code path is taken. [<0>] 0xc00000011c78f870 [<0>] __switch_to+0xfc/0x1a0 [<0>] pci_lock_rescan_remove+0x30/0x44 [<0>] eeh_rmv_device+0x290/0x2e0 [<0>] eeh_pe_dev_traverse+0x80/0x130 [<0>] eeh_reset_device+0xcc/0x23c [<0>] eeh_handle_normal_event+0x830/0xa80 [<0>] eeh_event_handler+0xf8/0x190 [<0>] kthread+0x194/0x1b0 [<0>] start_kernel_thread+0x14/0x18 The issue is seen for cases where the errors are detected on the PHB directly AND|OR for devices where the driver error_detected() returns PCI_ERS_RESULT_NEED_RESET, and driver being not EEH sensitive(i.e no error handlers like slot_reset(), resume() etc defined). Fixes: 1010b4c012b0 ("powerpc/eeh: Make EEH driver device hotplug safe") Cc: stable Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Shivaprasad G Bhat Reviewed-by: Amit Machhiwal Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/178404937381.913.2759874335293830160.stgit@linux.ibm.com

powerpc: pci-ioda: Fix the stale irq chip reference

2026-09-05T05:41:39+00:00

The commit f0ac60e6e311 ("powerpc/powernv/pci: Switch to use msi_create_parent_irq_domain()") removed the legacy MSI irq chip pnv_pci_msi_irq_chip but left behind the static definition of it and its reference in is_pnv_opal_msi(). The KVM IRQ bypass for vfio devices is broken because the comparision in is_pnv_opal_msi() fails on the comparision with stale unused variable showing the below errors in dmesg. kvmppc_set_passthru_irq_hv: Could not assign IRQ map for (X,Y) kvmppc_set_passthru_irq (irq X, gsi Y) fails: -2 vfio-pci A:B:C.D irq bypass producer (eventfd Z) registration fails: -2 The patch removes the stale variable definition and fixes the is_pnv_opal_msi() by comparing against the chip name prefix. Fixes: f0ac60e6e311 ("powerpc/powernv/pci: Switch to use msi_create_parent_irq_domain()") Cc: stable@kernel.org Signed-off-by: Shivaprasad G Bhat Tested-by: Gautam Menghani Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/178716225364.1437.6201568081502251835.stgit@linux.ibm.com