On Wed, 2022-12-28 at 10:39 +0100, Paolo Bonzini wrote: > On 12/28/22 01:21, Michal Luczaj wrote: > > Does it mean kvm_xen_hcall_evtchn_send() deadlocks in the same > > fashion? > > > > kvm_xen_eventfd_reset() > > mutex_lock() > > srcu_read_lock() > > kvm_xen_hcall_evtchn_send() > > kvm_xen_set_evtchn() > > mutex_lock() > > synchronize_srcu() > > Yes, I imagine that in practice you won't have running vCPUs during a > reset but the bug exists. Thanks! If it's just kvm_xen_evtchn_reset() I can fix that — and have to anyway, even if we switch the Xen code to its own lock. But what is the general case lock ordering rule here? Can other code call synchronize_srcu() while holding kvm->lock? Or is that verboten?
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
