diff options
author | David Woodhouse <dwmw@amazon.co.uk> | 2023-01-11 18:06:51 +0000 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2023-01-11 17:45:58 -0500 |
commit | 310bc39546a435c83cc27a0eba878afac0d74714 (patch) | |
tree | 82140b99c617ba7f4c085898cb68b1aa8f40fa11 /.gitattributes | |
parent | 42a90008f890afc41837dfeec1f0b1e7bcecf94a (diff) | |
download | linux-310bc39546a435c83cc27a0eba878afac0d74714.tar.bz2 |
KVM: x86/xen: Avoid deadlock by adding kvm->arch.xen.xen_lock leaf node lock
In commit 14243b387137a ("KVM: x86/xen: Add KVM_IRQ_ROUTING_XEN_EVTCHN
and event channel delivery") the clever version of me left some helpful
notes for those who would come after him:
/*
* For the irqfd workqueue, using the main kvm->lock mutex is
* fine since this function is invoked from kvm_set_irq() with
* no other lock held, no srcu. In future if it will be called
* directly from a vCPU thread (e.g. on hypercall for an IPI)
* then it may need to switch to using a leaf-node mutex for
* serializing the shared_info mapping.
*/
mutex_lock(&kvm->lock);
In commit 2fd6df2f2b47 ("KVM: x86/xen: intercept EVTCHNOP_send from guests")
the other version of me ran straight past that comment without reading it,
and introduced a potential deadlock by taking vcpu->mutex and kvm->lock
in the wrong order.
Solve this as originally suggested, by adding a leaf-node lock in the Xen
state rather than using kvm->lock for it.
Fixes: 2fd6df2f2b47 ("KVM: x86/xen: intercept EVTCHNOP_send from guests")
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Message-Id: <20230111180651.14394-4-dwmw2@infradead.org>
[Rebase, add docs. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to '.gitattributes')
0 files changed, 0 insertions, 0 deletions