summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorZenghui Yu (Huawei) <zenghui.yu@linux.dev>2026-10-29 20:16:48 +0800
committerMichael S. Tsirkin <mst@redhat.com>2026-11-03 07:32:14 -0500
commit1a577f9402c1780cc1e663f48d5dd54c02051b09 (patch)
treeec07f5e0779ca3184d1a21f95ccf54836582f88e /tools/perf/scripts/python
parent92368f4fb8ff40b87faa4acf1775720ffaf5749d (diff)
virtio_pci: don't take the MSI mutex under cpu_hotplug_lock
Lockdep reports the following circular locking dependency when a virtio-net device is probed with lockdep enabled on a system whose devices sit behind an IOMMU: ====================================================== WARNING: possible circular locking dependency detected 7.3.0-rc1+ #84 Not tainted ------------------------------------------------------ kworker/u34:0/57 is trying to acquire lock: ffff800104f83ee8 (&md->mutex){+.+.}-{4:4}, at: msi_domain_get_virq+0xf0/0x118 but task is already holding lock: ffffc00081edd930 (cpu_hotplug_lock){++++}-{0:0}, at: cpus_read_lock+0x10/0x1c which lock already depends on the new lock. Chain exists of: &md->mutex --> &group->mutex --> cpu_hotplug_lock The cycle is composed of three dependencies: * cpu_hotplug_lock -> &md->mutex (which triggers the splat). virtio_net's init_vqs() calls cpus_read_lock() around virtnet_set_affinity(), which reaches vp_set_vq_affinity(). That calls pci_irq_vector(), which takes the per-device MSI mutex (&dev->msi.data->mutex) via msi_domain_get_virq(). * &md->mutex -> &domain->mutex -> &group->mutex. MSI-X allocation of any device behind the IOMMU holds the MSI mutex while allocating interrupts through the IRQ domain hierarchy. The MSI parent domain (GICv2m, or ITS likewise) calls iommu_dma_prepare_msi() from its .alloc() to map the MSI doorbell, which takes the IOMMU group mutex. * &group->mutex -> cpu_hotplug_lock. bus_iommu_probe() calls iommu_setup_dma_ops() under the group mutex; initializing the IOVA rcaches registers a cpuhp instance, which takes cpu_hotplug_lock. The cycle only became complete since commit 288683c92b1a ("iommu: Make iommu_dma_prepare_msi() into a generic operation"), where iommu_dma_prepare_msi() switched to use the group mutex. pci_irq_vector() is a pure lookup of a vector that is bound to the queue for the whole lifetime of the queue, so there is no reason to take the MSI mutex for it from cpu hotplug locked contexts. Cache the IRQ number in virtio_pci_vq_info {} at vector binding time and make vp_set_vq_affinity() use the cached value. This also covers the CPU hotplug callbacks (virtnet_cpu_online/virtnet_cpu_dead), which call virtnet_set_affinity() with cpu_hotplug_lock already held. Signed-off-by: Zenghui Yu (Huawei) <zenghui.yu@linux.dev> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20261029121648.22155-1-zenghui.yu@linux.dev>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions