Skip to content

Commit 37bbf72

Browse files
committed
KVM: WARN if there are danging MMU invalidations at VM destruction
Add an assertion that there are no in-progress MMU invalidations when a VM is being destroyed, with the exception of the scenario where KVM unregisters its MMU notifier between an .invalidate_range_start() call and the corresponding .invalidate_range_end(). KVM can't detect unpaired calls from the mmu_notifier due to the above exception waiver, but the assertion can detect KVM bugs, e.g. such as the bug that *almost* escaped initial guest_memfd development. Link: https://lore.kernel.org/all/e397d30c-c6af-e68f-d18e-b4e3739c5389@linux.intel.com Link: https://lore.kernel.org/r/20230921203331.3746712-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
1 parent 1912c5d commit 37bbf72

File tree

1 file changed

+8
-1
lines changed

1 file changed

+8
-1
lines changed

virt/kvm/kvm_main.c

Lines changed: 8 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1381,9 +1381,16 @@ static void kvm_destroy_vm(struct kvm *kvm)
13811381
* No threads can be waiting in kvm_swap_active_memslots() as the
13821382
* last reference on KVM has been dropped, but freeing
13831383
* memslots would deadlock without this manual intervention.
1384+
*
1385+
* If the count isn't unbalanced, i.e. KVM did NOT unregister its MMU
1386+
* notifier between a start() and end(), then there shouldn't be any
1387+
* in-progress invalidations.
13841388
*/
13851389
WARN_ON(rcuwait_active(&kvm->mn_memslots_update_rcuwait));
1386-
kvm->mn_active_invalidate_count = 0;
1390+
if (kvm->mn_active_invalidate_count)
1391+
kvm->mn_active_invalidate_count = 0;
1392+
else
1393+
WARN_ON(kvm->mmu_invalidate_in_progress);
13871394
#else
13881395
kvm_flush_shadow_all(kvm);
13891396
#endif

0 commit comments

Comments
 (0)