kernel/git/stable/linux.git/arch/powerpc/sysdev/xive, branch master

powerpc/xive: defer setting cause_ipi until IPI init succeeds

2026-08-03T08:26:00+00:00

xive_smp_probe() currently assigns smp_ops->cause_ipi = xive_cause_ipi before calling xive_init_ipis() and xive_setup_cpu_ipi(). If either call fails, the platform probe handler returns early but cause_ipi remains pointing to xive_cause_ipi -- which accesses per-cpu IPI data (xc->ipi_data) that was never properly initialized, leading to a WARN and a crash. Move the cause_ipi assignment to after both calls succeed, so that smp_ops->cause_ipi is only set when the IPI subsystem is fully initialized. Signed-off-by: Gou Hao Suggested-by: Cédric Le Goater Reviewed-by: jiazhenyuan Reviewed-by: Cédric Le Goater Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260727104215.184786-5-gouhao@uniontech.com

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

2026-08-03T08:25:59+00:00

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

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

2026-08-03T08:25:59+00:00

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

powerpc/xive: make xive IPI allocation NULL-safe

2026-08-03T08:25:59+00:00

__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

powerpc/xive: Add warning if target CPU not found

2026-06-02T05:54:32+00:00

Add a warn_once to warn if the CPU target is not found. This could help to find about any such usecase. This is a very rare case, which either means mask was empty or atomic update failed for all online CPUs. So it is worth printing that path for potential fix. Signed-off-by: Shrikanth Hegde Reviewed-by: Yury Norov Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260427044715.559137-5-sshegde@linux.ibm.com

Merge tag 'powerpc-7.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux

2026-04-15T00:10:15+00:00

Pull powerpc updates from Madhavan Srinivasan: - powerpc support for huge pfnmaps - Cleanups to use masked user access - Rework pnv_ioda_pick_m64_pe() to use better bitmap API - Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC - Backup region offset update to eflcorehdr - Fixes for wii/ps3 platform - Implement JIT support for private stack in powerpc - Implement JIT support for fsession in powerpc64 trampoline - Add support for instruction array and indirect jump in powerpc - Misc selftest fixes and cleanups Thanks to Abhishek Dubey, Aditya Gupta, Alex Williamson, Amit Machhiwal, Andrew Donnellan, Bartosz Golaszewski, Cédric Le Goater, Chen Ni, Christophe Leroy (CS GROUP), Hari Bathini, J. Neuschäfer, Mukesh Kumar Chaurasiya (IBM), Nam Cao, Nilay Shroff, Pavithra Prakash, Randy Dunlap, Ritesh Harjani (IBM), Shrikanth Hegde, Sourabh Jain, Vaibhav Jain, Venkat Rao Bagalkote, and Yury Norov (NVIDIA) * tag 'powerpc-7.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: (47 commits) mailmap: Add entry for Andrew Donnellan powerpc32/bpf: fix loading fsession func metadata using PPC_LI32 selftest/bpf: Enable gotox tests for powerpc64 powerpc64/bpf: Add support for indirect jump selftest/bpf: Enable instruction array test for powerpc powerpc/bpf: Add support for instruction array powerpc32/bpf: Add fsession support powerpc64/bpf: Implement fsession support selftests/bpf: Enable private stack tests for powerpc64 powerpc64/bpf: Implement JIT support for private stack powerpc: pci-ioda: Optimize pnv_ioda_pick_m64_pe() powerpc: pci-ioda: use bitmap_alloc() in pnv_ioda_pick_m64_pe() powerpc/net: Inline checksum wrappers and convert to scoped user access powerpc/sstep: Convert to scoped user access powerpc/align: Convert emulate_spe() to scoped user access powerpc/ptrace: Convert gpr32_set_common_user() to scoped user access powerpc/futex: Use masked user access powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC cpuidle: powerpc: avoid double clear when breaking snooze powerpc/ps3: spu.c: fix enum and Return kernel-doc warnings ...

powerpc/xive: simplify xive_spapr_debug_show()

2026-04-09T17:28:05+00:00

The function creates temporary buffer to convert xibm->bitmap to a human-readable list before passing it to seq_printf. Drop it and print the list by seq_printf() directly with the "%*pbl" specifier. Reviewed-by: Shrikanth Hegde Acked-by: Madhavan Srinivasan for powerpc patch Signed-off-by: Yury Norov

powerpc/xive: rework xive_find_target_in_mask()

2026-04-01T03:51:04+00:00

Switch the function to using modern cpumask API and drop most of the housekeeping code. Notice, if first >= nr_cpu_ids, for_each_cpu_wrap() iterator behaves just like for_each_cpu(), i.e. begins from 0. So even if WARN_ON() is triggered, no special handling is needed. Signed-off-by: Yury Norov Tested-by: Mukesh Kumar Chaurasiya (IBM) Reviewed-by: Shrikanth Hegde Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260319033647.881246-3-ynorov@nvidia.com

Revert "powerpc/xive: Fix the size of the cpumask used in xive_find_target_in_mask()"

2026-04-01T03:51:04+00:00

This reverts commit a9dadc1c512807f955f0799e85830b420da47932. The commit message states: When called from xive_irq_startup(), the size of the cpumask can be larger than nr_cpu_ids. This can result in a WARN_ON. [...] This happens because we're being called with our affinity mask set to irq_default_affinity. That in turn was populated using cpumask_setall(), which sets NR_CPUs worth of bits, not nr_cpu_ids worth. Finally cpumask_weight() will return > nr_cpu_ids when passed a mask which has > nr_cpu_ids bits set. In modern kernel, cpumask_weight() can't return > nr_cpu_ids. In inline case, cpumask_setall() explicitly clears all bits above nr_cpu_ids, see commit 63355b9884b3 ("cpumask: be more careful with 'cpumask_setall()'"). So, despite that cpumask_weight() is passed with small_cpumask_bits, which is NR_CPUS in this case, it can't count over the nr_cpu_ids. In outline case, cpumask_setall() may set bits beyond the limit up to the next byte alignment, but in this case small_cpumask_bits is wired to nr_cpu_ids, thus making overcounting impossible. Signed-off-by: Yury Norov Tested-by: Mukesh Kumar Chaurasiya (IBM) Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260319033647.881246-2-ynorov@nvidia.com

powerpc/xive: fix kmemleak caused by incorrect chip_data lookup

2026-03-30T10:45:57+00:00

The kmemleak reports the following memory leak: Unreferenced object 0xc0000002a7fbc640 (size 64): comm "kworker/8:1", pid 540, jiffies 4294937872 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 09 04 00 04 00 00 ................ 00 00 a7 81 00 00 0a c0 00 00 08 04 00 04 00 00 ................ backtrace (crc 177d48f6): __kmalloc_cache_noprof+0x520/0x730 xive_irq_alloc_data.constprop.0+0x40/0xe0 xive_irq_domain_alloc+0xd0/0x1b0 irq_domain_alloc_irqs_parent+0x44/0x6c pseries_irq_domain_alloc+0x1cc/0x354 irq_domain_alloc_irqs_parent+0x44/0x6c msi_domain_alloc+0xb0/0x220 irq_domain_alloc_irqs_locked+0x138/0x4d0 __irq_domain_alloc_irqs+0x8c/0xfc __msi_domain_alloc_irqs+0x214/0x4d8 msi_domain_alloc_irqs_all_locked+0x70/0xf8 pci_msi_setup_msi_irqs+0x60/0x78 __pci_enable_msix_range+0x54c/0x98c pci_alloc_irq_vectors_affinity+0x16c/0x1d4 nvme_pci_enable+0xac/0x9c0 [nvme] nvme_probe+0x340/0x764 [nvme] This occurs when allocating MSI-X vectors for an NVMe device. During allocation the XIVE code creates a struct xive_irq_data and stores it in irq_data->chip_data. When the MSI-X irqdomain is later freed, xive_irq_free_data() is responsible for retrieving this structure and freeing it. However, after commit cc0cc23babc9 ("powerpc/xive: Untangle xive from child interrupt controller drivers"), xive_irq_free_data() retrieves the chip_data using irq_get_chip_data(), which looks up the data through the child domain. This is incorrect because the XIVE-specific irq data is associated with the XIVE (parent) domain. As a result the lookup fails and the allocated struct xive_irq_data is never freed, leading to the kmemleak report shown above. Fix this by retrieving the irq_data from the correct domain using irq_domain_get_irq_data() and then accessing the chip_data via irq_data_get_irq_chip_data(). Cc: stable@vger.kernel.org Fixes: cc0cc23babc9 ("powerpc/xive: Untangle xive from child interrupt controller drivers") Signed-off-by: Nilay Shroff Tested-by: Venkat Rao Bagalkote Reviewed-by: Nam Cao Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260311134336.326996-1-nilay@linux.ibm.com