Messages in this thread | | | From | Paolo Bonzini <> | Subject | Re: [PATCH 16/18] KVM: Don't take mmu_lock for range invalidation unless necessary | Date | Wed, 31 Mar 2021 23:35:37 +0200 |
| |
On 31/03/21 23:05, Sean Christopherson wrote: >> Wouldn't it be incorrect to lock a mutex (e.g. inside*another* MMU >> notifier's invalidate callback) while holding an rwlock_t? That makes sense >> because anybody that's busy waiting in write_lock potentially cannot be >> preempted until the other task gets the mutex. This is a potential >> deadlock. > > Yes? I don't think I follow your point though. Nesting a spinlock or rwlock > inside a rwlock is ok, so long as the locks are always taken in the same order, > i.e. it's never mmu_lock -> mmu_notifier_slots_lock.
*Another* MMU notifier could nest a mutex inside KVM's rwlock.
But... is it correct that the MMU notifier invalidate callbacks are always called with the mmap_sem taken (sometimes for reading, e.g. try_to_merge_with_ksm_page->try_to_merge_one_page->write_protect_page)? We could take it temporarily in install_memslots, since the MMU notifier's mm is stored in kvm->mm.
In this case, a pair of kvm_mmu_notifier_lock/unlock functions would be the best way to abstract it.
Paolo
| |