kernel/linux.git/arch/powerpc/sysdev/xive/common.c, branch v6.18.33

powerpc/xive: fix kmemleak caused by incorrect chip_data lookup

2026-05-14T13:30:21+00:00

commit 6771c54728c278bf1e4bfdab4fddbbb186e33498 upstream. 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 Signed-off-by: Greg Kroah-Hartman

powerpc, ocxl: Fix extraction of struct xive_irq_data

2025-10-13T04:10:55+00:00

Commit cc0cc23babc9 ("powerpc/xive: Untangle xive from child interrupt controller drivers") changed xive_irq_data to be stashed to chip_data instead of handler_data. However, multiple places are still attempting to read xive_irq_data from handler_data and get a NULL pointer deference bug. Update them to read xive_irq_data from chip_data. Non-XIVE files which touch xive_irq_data seem quite strange to me, especially the ocxl driver. I think there ought to be an alternative platform-independent solution, instead of touching XIVE's data directly. Therefore, I think this whole thing should be cleaned up. But perhaps I just misunderstand something. In any case, this cleanup would not be trivial; for now, just get things working again. Fixes: cc0cc23babc9 ("powerpc/xive: Untangle xive from child interrupt controller drivers") Reported-by: Ritesh Harjani (IBM) Closes: https://lore.kernel.org/linuxppc-dev/68e48df8.170a0220.4b4b0.217d@mx.google.com/ Signed-off-by: Nam Cao Reviewed-by: Ganesh Goudar Acked-by: Andrew Donnellan # ocxl Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20251008081359.1382699-1-namcao@linutronix.de

powerpc/xive: Untangle xive from child interrupt controller drivers

2025-09-06T12:03:18+00:00

xive-specific data is stored in handler_data. This creates a mess, as xive has to rely on child interrupt controller drivers to clean up this data, as was done by 9a014f45688 ("powerpc/pseries/pci: Add a msi_free() handler to clear XIVE data"). Instead, store xive-specific data in chip_data and untangle the child drivers. Signed-off-by: Nam Cao Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/83968073022a4cc211dcbd0faccd20ec05e58c3e.1754903590.git.namcao@linutronix.de

powerpc: Switch to irq_domain_create_*()

2025-05-16T19:06:11+00:00

irq_domain_add_*() interfaces are going away as being obsolete now. Switch to the preferred irq_domain_create_*() ones. Those differ in the node parameter: They take more generic struct fwnode_handle instead of struct device_node. Therefore, of_fwnode_handle() is added around the original parameter. Note some of the users can likely use dev->fwnode directly instead of indirect of_fwnode_handle(dev->of_node). But dev->fwnode is not guaranteed to be set for all, so this has to be investigated on case to case basis (by people who can actually test with the HW). [ tglx: Fix up subject prefix ] Signed-off-by: Jiri Slaby (SUSE) Signed-off-by: Thomas Gleixner Reviewed-by: Christophe Leroy # For 8xx Link: https://lore.kernel.org/all/20250319092951.37667-33-jirislaby@kernel.org

irqdomain: Rename irq_set_default_host() to irq_set_default_domain()

2025-04-04T14:39:10+00:00

Naming interrupt domains host is confusing at best and the irqdomain code uses both domain and host inconsistently. Therefore rename irq_set_default_host() to irq_set_default_domain(). Signed-off-by: Jiri Slaby (SUSE) Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20250319092951.37667-3-jirislaby@kernel.org

powerpc/xive: Use cpumask_intersects()

2024-11-14T11:43:52+00:00

Replace `cpumask_any_and(a, b) >= nr_cpu_ids` with the more readable `!cpumask_intersects(a, b)`. Comparison between cpumask_any_and() and cpumask_intersects() The cpumask_any_and() function expands using FIND_FIRST_BIT(), resulting in a loop that iterates through each bit of the bitmask: for (idx = 0; idx * BITS_PER_LONG < sz; idx++) { val = (FETCH); if (val) { sz = min(idx * BITS_PER_LONG + __ffs(MUNGE(val)), sz); break; } } The cpumask_intersects() function expands using __bitmap_intersects(), resulting in that the first loop iterates through each long word of the bitmask, and the second through each bit within a long word: unsigned int k, lim = bits/BITS_PER_LONG; for (k = 0; k < lim; ++k) if (bitmap1[k] & bitmap2[k]) return true; if (bits % BITS_PER_LONG) if ((bitmap1[k] & bitmap2[k]) & BITMAP_LAST_WORD_MASK(bits)) return true; Conclusion: cpumask_intersects() is at least as efficient as cpumask_any_and(), if not more so, as it typically performs fewer loops and comparisons. Signed-off-by: Costa Shulyupin Reviewed-by: Ming Lei Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Michael Ellerman Link: https://patch.msgid.link/20240926092623.399577-2-costa.shul@redhat.com

powerpc: Fix typos

2024-05-07T14:21:30+00:00

Fix typos, most reported by "codespell arch/powerpc". Only touches comments, no code changes. Signed-off-by: Bjorn Helgaas Signed-off-by: Michael Ellerman Link: https://msgid.link/20240103231605.1801364-8-helgaas@kernel.org

powerpc/xive: fix repeated words in comments

2022-09-06T01:03:04+00:00

Delete the redundant word 'set'. Signed-off-by: Jilin Yuan Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220831004706.35280-1-yuanjilin@cdjrlc.com

powerpc/kasan: Disable address sanitization in kexec paths

2022-05-22T05:58:29+00:00

The kexec code paths involve code that necessarily run in real mode, as CPUs are disabled and control is transferred to the new kernel. Disable address sanitization for the kexec code and the functions called in real mode on CPUs being disabled. [paulus@ozlabs.org: combined a few work-in-progress commits of Daniel's and wrote the commit message.] Signed-off-by: Daniel Axtens Signed-off-by: Paul Mackerras [mpe: Move pseries_machine_kexec() into kexec.c so setup.c can be instrumented] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/YoTFSQ2TUSEaDdVC@cleo

powerpc: Add missing headers

2022-05-08T12:15:40+00:00

Don't inherit headers "by chances" from asm/prom.h, asm/mpc52xx.h, asm/pci.h etc... Include the needed headers, and remove asm/prom.h when it was needed exclusively for pulling necessary headers. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/be8bdc934d152a7d8ee8d1a840d5596e2f7d85e0.1646767214.git.christophe.leroy@csgroup.eu