KVM: fix fault page leak
PATCH 1/3 KVM: fix fault page leak
fault_page is forgot to be freed
--- virt/kvm/kvm_main.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
virt/kvm/kvm_main.c +1 -0
@@ -2857,6 +2857,7 @@ void kvm_exit(void)kvm_arch_hardware_unsetup ();kvm_arch_exit ();free_cpumask_var (cpus_hardware_enabled); +__free_page (fault_page);__free_page (hwpoison_page);__free_page (bad_page); }
Signature · 1 line
1.7.7.6
PATCH 2/3 KVM: MMU: fix shrinking page from the empty mmu
Fix:
[ 3190.059226] BUG: unable to handle kernel NULL pointer dereference at (null) [ 3190.062224] IP: [<ffffffffa02aac66>] mmu_page_zap_pte+0x10/0xa7 [kvm] [ 3190.063760] PGD 104f50067 PUD 112bea067 PMD 0 [ 3190.065309] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC [ 3190.066860] CPU 1 [ ...... ] [ 3190.109629] Call Trace: [ 3190.111342] [<ffffffffa02aada6>] kvm_mmu_prepare_zap_page+0xa9/0x1fc [kvm] [ 3190.113091] [<ffffffffa02ab2f5>] mmu_shrink+0x11f/0x1f3 [kvm] [ 3190.114844] [<ffffffffa02ab25d>] ? mmu_shrink+0x87/0x1f3 [kvm] [ 3190.116598] [<ffffffff81150c9d>] ? prune_super+0x142/0x154 [ 3190.118333] [<ffffffff8110a4f4>] ? shrink_slab+0x39/0x31e [ 3190.120043] [<ffffffff8110a687>] shrink_slab+0x1cc/0x31e [ 3190.121718] [<ffffffff8110ca1d>] do_try_to_free_pages
This is caused by shrinking page from the empty mmu, although we have checked n_used_mmu_pages, it is useless since the check is out of mmu-lock
--- arch/x86/kvm/mmu.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
arch/x86/kvm/mmu.c +3 -0
@@ -3936,6 +3936,9 @@ static void kvm_mmu_remove_some_alloc_mmu_pages(struct kvm *kvm, {struct kvm_mmu_page *page; +if (list_empty (&kvm->arch.active_mmu_pages)) +return ; + page =container_of (kvm->arch.active_mmu_pages.prev, struct kvm_mmu_page, link);kvm_mmu_prepare_zap_page (kvm, page, invalid_list);
Signature · 1 line
1.7.7.6
PATCH 3/3 KVM: MMU: track the refcount when unmap the page
In reply to Xiao GuangrongIt will trigger a WARN_ON if the page has been freed but it is still used in mmu, it can help us to detect mm bug early
--- arch/x86/kvm/mmu.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
arch/x86/kvm/mmu.c +8 -0
@@ -527,6 +527,14 @@ static int mmu_spte_clear_track_bits(u64 *sptep)return 0 ; pfn =spte_to_pfn (old_spte); + +/* +* KVM does not hold the refcount of the page used by +* kvm mmu, before reclaiming the page, we should +* unmap it from mmu first. +*/ +WARN_ON (!page_count (pfn_to_page (pfn))); +if (!shadow_accessed_mask || old_spte & shadow_accessed_mask)kvm_set_pfn_accessed (pfn);if (!shadow_dirty_mask || (old_spte & shadow_dirty_mask))
Signature · 1 line
1.7.7.6
Marcelo Tosatti
AppliedRe: [PATCH 3/3] KVM: MMU: track the refcount when unmap the page
Quoted 14 lines · Xiao Guangrong
It will trigger a
WARN_ONif the page has been freed but it is still used in mmu, it can help us to detect mm bug earlySigned-off-by Xiao Guangrong <[email protected]>--- arch/x86/kvm/mmu.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)arch/x86/kvm/mmu.c +0
-0@@ -527,6 +527,14 @@ static int mmu_spte_clear_track_bits(u64 *sptep)return 0 ;
arch/x86/kvm/mmu.c static int mmu_spte_clear_track_bits(u64 *sptep) · line 537
Quoted 10 lines
arch/x86/kvm/mmu.c +8
-0pfn =spte_to_pfn (old_spte); + +/* +* KVM does not hold the refcount of the page used by +* kvm mmu, before reclaiming the page, we should +* unmap it from mmu first. +*/ +WARN_ON (!page_count (pfn_to_page (pfn))); +
Except for mmio pfns.
Applied patch 1 and 2 to master, thanks.