All of lore.kernel.org
 help / color / mirror / Atom feed
* Spinlock inversion in amd/iommu_init
@ 2014-12-18 18:02 Andrew Cooper
  0 siblings, 0 replies; only message in thread
From: Andrew Cooper @ 2014-12-18 18:02 UTC (permalink / raw)
  To: Suravee Suthikulpanit, Aravind Gopalakrishnan; +Cc: Jan Beulich, Xen-devel List

Hi,

XenServers Coverity scanning has identified a spinlock inversion, where
enable_iommu() takes the iommu lock and irq_desc lock in an opposite
order to the rest of the interrupt handling.  (I suspect Coverity Scan
is not identifying this as it is not configured to perform function
pointer analysis.)

This codepath is used during boot, and on resume from S3, and presumably
has not been hit in practice as the irq_desc lock is only taken when
interrupts from the IOMMU are quiesced.

In terms of fixing the locking inversion, I think the affinity setting
part of enable_iommu() can safely move to set_iommu_interrupt_handler().

Having said that, it occurs to me that nothing currently changes the msi
affinity at all, as cpus come up and down.  Furthermore, it seems unwise
to have the affinity any bigger than the local numa set anyway, as this
interrupt is specifically not associated with a vcpu.

~Andrew

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2014-12-18 18:02 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-18 18:02 Spinlock inversion in amd/iommu_init Andrew Cooper

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.