x86/IRQ: fix locking around vector management
authorJan Beulich <jbeulich@suse.com>
Mon, 22 Jul 2019 09:44:02 +0000 (11:44 +0200)
committerJan Beulich <jbeulich@suse.com>
Mon, 22 Jul 2019 09:44:02 +0000 (11:44 +0200)
commit650c31d3af8a6a4a7174633f93ed9405e9c8d279
treebc3e4f1265d6d419060c3133d25d51ebbb73f7e4
parent481a478b3af4b1b33f9a121192a743f17a901457
x86/IRQ: fix locking around vector management

All of __{assign,bind,clear}_irq_vector() manipulate struct irq_desc
fields, and hence ought to be called with the descriptor lock held in
addition to vector_lock. This is currently the case for only
set_desc_affinity() (in the common case) and destroy_irq(), which also
clarifies what the nesting behavior between the locks has to be.
Reflect the new expectation by having these functions all take a
descriptor as parameter instead of an interrupt number.

Also take care of the two special cases of calls to set_desc_affinity():
set_ioapic_affinity_irq() and VT-d's dma_msi_set_affinity() get called
directly as well, and in these cases the descriptor locks hadn't got
acquired till now. For set_ioapic_affinity_irq() this means acquiring /
releasing of the IO-APIC lock can be plain spin_{,un}lock() then.

Drop one of the two leading underscores from all three functions at
the same time.

There's one case left where descriptors get manipulated with just
vector_lock held: setup_vector_irq() assumes its caller to acquire
vector_lock, and hence can't itself acquire the descriptor locks (wrong
lock order). I don't currently see how to address this.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com> [VT-d]
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
xen/arch/x86/io_apic.c
xen/arch/x86/irq.c
xen/drivers/passthrough/vtd/iommu.c