On Wed, 2023-01-11 at 13:30 -0500, Paolo Bonzini wrote: > > +- ``synchronize_srcu(&kvm->srcu)`` is called inside critical sections > + for kvm->lock, vcpu->mutex and kvm->slots_lock. These locks _cannot_ > + be taken inside a kvm->srcu read-side critical section; that is, the > + following is broken:: > + > + srcu_read_lock(&kvm->srcu); > + mutex_lock(&kvm->slots_lock); > + "Don't tell me. Tell lockdep!" Did we conclude in https://lore.kernel.org/kvm/122f38e724aae9ae8ab474233da1ba19760c20d2.camel@xxxxxxxxxxxxx/ that lockdep *could* be clever enough to catch a violation of this rule by itself? The general case of the rule would be that 'if mutex A is taken in a read-section for SCRU B, then any synchronize_srcu(B) while mutex A is held shall be verboten'. And vice versa. If we can make lockdep catch it automatically, yay! If not, I'm inclined to suggest that we have explicit wrappers of our own for kvm_mutex_lock() which will do the check directly.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
