On Fri, 2023-01-06 at 00:02 +0100, Paolo Bonzini wrote: > On 1/5/23 23:23, Sean Christopherson wrote: > > Ha! Case in point. The aforementioned Xen code blatantly violates KVM's locking > > rules: > > > > - kvm->lock is taken outside vcpu->mutex > > Ouch yeah, that's not salvageable. Anything that takes kvm->lock inside > kvm->srcu transitively has to be taking kvm->lock inside vcpu->mutex as > well. > > In abstract I don't think that "vcpu->mutex inside kvm->lock" would be a > particularly problematic rule; kvm->lock critical sections are much > shorter than vcpu->mutex which covers all of KVM_RUN for example, and > that hints at making vcpu->mutex the *outer* mutex. However, I > completely forgot the sev_lock_vcpus_for_migration case, which is the > exception that... well, disproves the rule. > But because it's an exception and rarely happens in practice, lockdep didn't notice and keep me honest sooner? Can we take them in that order just for fun at startup, to make sure lockdep knows? > Fortunately, it's pretty easy to introduce a new lock just for xen.c and > revert the docs patch. The wording of that made me hold off, on the expectation that if I did it myself, you'd probably beat me to it with a patch. But I don't see one yet. Shall I?
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
