Message ID | 20221228110410.1682852-1-pbonzini@redhat.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | KVM: x86: fix deadlock for KVM_XEN_EVTCHN_RESET | expand |
Hi Paolo, > diff --git a/tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c b/tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c > index 721f6a693799..dae510c263b4 100644 > --- a/tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c > +++ b/tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c > @@ -962,6 +962,12 @@ int main(int argc, char *argv[]) > } > > done: > + struct kvm_xen_hvm_attr evt_reset = { > + .type = KVM_XEN_ATTR_TYPE_EVTCHN, > + .u.evtchn.flags = KVM_XEN_EVTCHN_RESET, > + }; > + vm_ioctl(vm, KVM_XEN_HVM_SET_ATTR, &evt_reset); > + > alarm(0); > clock_gettime(CLOCK_REALTIME, &max_ts); > This change generates a build failure with error message: "error: a label can only be part of a statement and a declaration is not a statement". Moving the definition of evt_reset to the beginning of main() can fix it: diff --git a/tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c b/tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c index dae510c263b4..d71f1508bb21 100644 --- a/tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c +++ b/tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c @@ -623,6 +623,10 @@ int main(int argc, char *argv[]) rs->state = 0x5a; bool evtchn_irq_expected = false; + struct kvm_xen_hvm_attr evt_reset = { + .type = KVM_XEN_ATTR_TYPE_EVTCHN, + .u.evtchn.flags = KVM_XEN_EVTCHN_RESET, + }; for (;;) { volatile struct kvm_run *run = vcpu->run; @@ -962,10 +966,6 @@ int main(int argc, char *argv[]) } done: - struct kvm_xen_hvm_attr evt_reset = { - .type = KVM_XEN_ATTR_TYPE_EVTCHN, - .u.evtchn.flags = KVM_XEN_EVTCHN_RESET, - }; vm_ioctl(vm, KVM_XEN_HVM_SET_ATTR, &evt_reset); alarm(0); B.R. Yu
On Thu, Jan 19, 2023, Yu Zhang wrote: > Hi Paolo, > > > diff --git a/tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c b/tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c > > index 721f6a693799..dae510c263b4 100644 > > --- a/tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c > > +++ b/tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c > > @@ -962,6 +962,12 @@ int main(int argc, char *argv[]) > > } > > > > done: > > + struct kvm_xen_hvm_attr evt_reset = { > > + .type = KVM_XEN_ATTR_TYPE_EVTCHN, > > + .u.evtchn.flags = KVM_XEN_EVTCHN_RESET, > > + }; > > + vm_ioctl(vm, KVM_XEN_HVM_SET_ATTR, &evt_reset); > > + > > alarm(0); > > clock_gettime(CLOCK_REALTIME, &max_ts); > > > > This change generates a build failure with error message: > "error: a label can only be part of a statement and a declaration is not a statement". And other flavors too, e.g. x86_64/xen_shinfo_test.c:965:2: error: expected expression struct kvm_xen_hvm_attr evt_reset = { ^ x86_64/xen_shinfo_test.c:969:38: error: use of undeclared identifier 'evt_reset' vm_ioctl(vm, KVM_XEN_HVM_SET_ATTR, &evt_reset); ^ x86_64/xen_shinfo_test.c:969:38: error: use of undeclared identifier 'evt_reset' 3 errors generated. make: *** [../lib.mk:145: tools/testing/selftests/kvm/x86_64/xen_shinfo_test] Error 1 make: *** Waiting for unfinished jobs.... I'm surprised bots haven't complained about this, haven't seen any reports. > Moving the definition of evt_reset to the beginning of main() can fix it: I'll queue a patch, this is already in Linus' tree and I've collected a few other tiny fixes for v6.2-rcwhatever that I'll send to Paolo. Thanks!
On Thu, Jan 19, 2023 at 6:57 PM Sean Christopherson <seanjc@google.com> wrote: > > This change generates a build failure with error message: > > "error: a label can only be part of a statement and a declaration is not a statement". > > And other flavors too, e.g. > > x86_64/xen_shinfo_test.c:965:2: error: expected expression > struct kvm_xen_hvm_attr evt_reset = { > ^ > x86_64/xen_shinfo_test.c:969:38: error: use of undeclared identifier 'evt_reset' > vm_ioctl(vm, KVM_XEN_HVM_SET_ATTR, &evt_reset); > ^ > x86_64/xen_shinfo_test.c:969:38: error: use of undeclared identifier 'evt_reset' > 3 errors generated. > make: *** [../lib.mk:145: tools/testing/selftests/kvm/x86_64/xen_shinfo_test] Error 1 > make: *** Waiting for unfinished jobs.... > > I'm surprised bots haven't complained about this, haven't seen any reports. It's clang only; GCC only warns with -Wpedantic. Plus, bots probably don't compile tools/ that much. Paolo
On Thu, Jan 19, 2023, Paolo Bonzini wrote: > On Thu, Jan 19, 2023 at 6:57 PM Sean Christopherson <seanjc@google.com> wrote: > > > This change generates a build failure with error message: > > > "error: a label can only be part of a statement and a declaration is not a statement". > > > > And other flavors too, e.g. > > > > x86_64/xen_shinfo_test.c:965:2: error: expected expression > > struct kvm_xen_hvm_attr evt_reset = { > > ^ > > x86_64/xen_shinfo_test.c:969:38: error: use of undeclared identifier 'evt_reset' > > vm_ioctl(vm, KVM_XEN_HVM_SET_ATTR, &evt_reset); > > ^ > > x86_64/xen_shinfo_test.c:969:38: error: use of undeclared identifier 'evt_reset' > > 3 errors generated. > > make: *** [../lib.mk:145: tools/testing/selftests/kvm/x86_64/xen_shinfo_test] Error 1 > > make: *** Waiting for unfinished jobs.... > > > > I'm surprised bots haven't complained about this, haven't seen any reports. > > It's clang only; GCC only warns with -Wpedantic. Plus, bots probably > don't compile tools/ that much. /wave Want to queue Yu's fix directly Paolo? I was assuming you'd be offline until sometime tomorrow.
On Thu, Jan 19, 2023 at 7:04 PM Sean Christopherson <seanjc@google.com> wrote: > > It's clang only; GCC only warns with -Wpedantic. Plus, bots probably > > don't compile tools/ that much. > > /wave > > Want to queue Yu's fix directly Paolo? I was assuming you'd be offline until > sometime tomorrow. Yes, I can, but what other patches were you meaning to send? Paolo
On Thu, Jan 19, 2023, Paolo Bonzini wrote: > On Thu, Jan 19, 2023 at 7:04 PM Sean Christopherson <seanjc@google.com> wrote: > > > It's clang only; GCC only warns with -Wpedantic. Plus, bots probably > > > don't compile tools/ that much. > > > > /wave > > > > Want to queue Yu's fix directly Paolo? I was assuming you'd be offline until > > sometime tomorrow. > > Yes, I can, but what other patches were you meaning to send? A minor selftest fix https://lore.kernel.org/all/20230111183408.104491-1-vipinsh@google.com and a fix for a longstanding VMX bug that seems problematic enough that it warrants going into this cycle. https://lore.kernel.org/all/20221114164823.69555-1-hborghor@amazon.de
On Thu, Jan 19, 2023 at 7:15 PM Sean Christopherson <seanjc@google.com> wrote: > A minor selftest fix > > https://lore.kernel.org/all/20230111183408.104491-1-vipinsh@google.com > > and a fix for a longstanding VMX bug that seems problematic enough that it > warrants going into this cycle. > > https://lore.kernel.org/all/20221114164823.69555-1-hborghor@amazon.de Ok, I had seen the latter so I'll put together a pull request. Paolo
On 28/12/2022 12:04, Paolo Bonzini wrote: > While KVM_XEN_EVTCHN_RESET is usually called with no vCPUs running, > if that happened it could cause a deadlock. This is due to > kvm_xen_eventfd_reset() doing a synchronize_srcu() inside > a kvm->lock critical section. > > [...] > > + /* > + * Because synchronize_srcu() cannot be called inside the > + * critical section, first collect all the evtchnfd objects > + * in an array as they are removed from evtchn_ports. > + */ With the recent changes regarding the locking order (locking.rst: "synchronize_srcu(&kvm->srcu) is called inside critical sections for kvm->lock, vcpu->mutex and kvm->slots_lock"), is this comment still valid? Or is there a rule that forbids synchronize_srcu() under the newly introduced kvm->arch.xen.xen_lock? thanks, Michal
diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c index b178f40bd863..2e29bdc2949c 100644 --- a/arch/x86/kvm/xen.c +++ b/arch/x86/kvm/xen.c @@ -1942,18 +1942,42 @@ static int kvm_xen_eventfd_deassign(struct kvm *kvm, u32 port) static int kvm_xen_eventfd_reset(struct kvm *kvm) { - struct evtchnfd *evtchnfd; + struct evtchnfd *evtchnfd, **all_evtchnfds; int i; + int n = 0; mutex_lock(&kvm->lock); + + /* + * Because synchronize_srcu() cannot be called inside the + * critical section, first collect all the evtchnfd objects + * in an array as they are removed from evtchn_ports. + */ + idr_for_each_entry(&kvm->arch.xen.evtchn_ports, evtchnfd, i) + n++; + + all_evtchnfds = kmalloc_array(n, sizeof(struct evtchnfd *), GFP_KERNEL); + if (!all_evtchnfds) { + mutex_unlock(&kvm->lock); + return -ENOMEM; + } + + n = 0; idr_for_each_entry(&kvm->arch.xen.evtchn_ports, evtchnfd, i) { + all_evtchnfds[n++] = evtchnfd; idr_remove(&kvm->arch.xen.evtchn_ports, evtchnfd->send_port); - synchronize_srcu(&kvm->srcu); + } + mutex_unlock(&kvm->lock); + + synchronize_srcu(&kvm->srcu); + + while (n--) { + evtchnfd = all_evtchnfds[n]; if (!evtchnfd->deliver.port.port) eventfd_ctx_put(evtchnfd->deliver.eventfd.ctx); kfree(evtchnfd); } - mutex_unlock(&kvm->lock); + kfree(all_evtchnfds); return 0; } diff --git a/tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c b/tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c index 721f6a693799..dae510c263b4 100644 --- a/tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c +++ b/tools/testing/selftests/kvm/x86_64/xen_shinfo_test.c @@ -962,6 +962,12 @@ int main(int argc, char *argv[]) } done: + struct kvm_xen_hvm_attr evt_reset = { + .type = KVM_XEN_ATTR_TYPE_EVTCHN, + .u.evtchn.flags = KVM_XEN_EVTCHN_RESET, + }; + vm_ioctl(vm, KVM_XEN_HVM_SET_ATTR, &evt_reset); + alarm(0); clock_gettime(CLOCK_REALTIME, &max_ts);
While KVM_XEN_EVTCHN_RESET is usually called with no vCPUs running, if that happened it could cause a deadlock. This is due to kvm_xen_eventfd_reset() doing a synchronize_srcu() inside a kvm->lock critical section. To avoid this, first collect all the evtchnfd objects in an array and free all of them once the kvm->lock critical section is over and th SRCU grace period has expired. Reported-by: Michal Luczaj <mhal@rbox.co> Cc: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> --- arch/x86/kvm/xen.c | 30 +++++++++++++++++-- .../selftests/kvm/x86_64/xen_shinfo_test.c | 6 ++++ 2 files changed, 33 insertions(+), 3 deletions(-)