FAILED: patch "[PATCH] KVM: MMU: Do not treat ZONE_DEVICE pages as being reserved" failed to apply to 4.19-stable tree

PATCH [email protected] 3 participants 5 messages Nov 18, 2019 – Nov 25, 2019

Subsystems (4)

Stable branch x86 KVM KVM x86

lore

Share & tools

lore

[email protected]

author maintainer

2019-11-18 15:22 UTC #0 lore raw

The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From a78986aae9b2988f8493f9f65a587ee433e83bc3 Mon Sep 17 00:00:00 2001
From: Sean Christopherson <[email protected]>
Date: Mon, 11 Nov 2019 14:12:27 -0800
Subject: [PATCH] KVM: MMU: Do not treat ZONE_DEVICE pages as being reserved

Explicitly exempt ZONE_DEVICE pages from kvm_is_reserved_pfn() and instead manually handle ZONE_DEVICE on a case-by-case basis. For things like page refcounts, KVM needs to treat ZONE_DEVICE pages like normal pages, e.g. put pages grabbed via gup(). But for flows such as setting A/D bits or shifting refcounts for transparent huge pages, KVM needs to to avoid processing ZONE_DEVICE pages as the flows in question lack the underlying machinery for proper handling of ZONE_DEVICE pages.

This fixes a hang reported by Adam Borowski[*] in dev_pagemap_cleanup() when running a KVM guest backed with /dev/dax memory, as KVM straight up doesn't put any references to ZONE_DEVICE pages acquired by gup().

Note, Dan Williams proposed an alternative solution of doing put_page() on ZONE_DEVICE pages immediately after gup() in order to simplify the auditing needed to ensure is_zone_device_page() is called if and only if the backing device is pinned (via gup()). But that approach would break kvm_vcpu_{un}map() as KVM requires the page to be pinned from map() 'til unmap() when accessing guest memory, unlike KVM's secondary MMU, which coordinates with mmu_notifier invalidations to avoid creating stale page references, i.e. doesn't rely on pages being pinned.

[*] http://lkml.kernel.org/r/[email protected]

Reported-by Adam Borowski <[email protected]>

Analyzed-by David Hildenbrand <[email protected]>

Acked-by Dan Williams <[email protected]>

Cc [email protected]

Fixes 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")

Signed-off-by Sean Christopherson <[email protected]>

Signed-off-by Paolo Bonzini <[email protected]>

arch/x86/kvm/mmu.c +4 -4

index 24c23c66b226..bf82b1f2e834 100644
@@ -3306,7 +3306,7 @@ static void transparent_hugepage_adjust(struct kvm_vcpu *vcpu,
 	 * here.
 	 */
 	if (!is_error_noslot_pfn(pfn) && !kvm_is_reserved_pfn(pfn) &&
-	    level == PT_PAGE_TABLE_LEVEL &&
+	    !kvm_is_zone_device_pfn(pfn) && level == PT_PAGE_TABLE_LEVEL &&
 	    PageTransCompoundMap(pfn_to_page(pfn)) &&
 	    !mmu_gfn_lpage_is_disallowed(vcpu, gfn, PT_DIRECTORY_LEVEL)) {
 		unsigned long mask;

@@ -5914,9 +5914,9 @@ static bool kvm_mmu_zap_collapsible_spte(struct kvm *kvm,
 		 * the guest, and the guest page table is using 4K page size
 		 * mapping if the indirect sp has level = 1.
 		 */
-		if (sp->role.direct &&
-			!kvm_is_reserved_pfn(pfn) &&
-			PageTransCompoundMap(pfn_to_page(pfn))) {
+		if (sp->role.direct && !kvm_is_reserved_pfn(pfn) &&
+		    !kvm_is_zone_device_pfn(pfn) &&
+		    PageTransCompoundMap(pfn_to_page(pfn))) {
 			pte_list_remove(rmap_head, sptep);
 
 			if (kvm_available_flush_tlb_with_range())

include/linux/kvm_host.h +1 -0

index 719fc3e15ea4..290dbe353a47 100644
@@ -966,6 +966,7 @@ int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu);
 void kvm_vcpu_kick(struct kvm_vcpu *vcpu);
 
 bool kvm_is_reserved_pfn(kvm_pfn_t pfn);
+bool kvm_is_zone_device_pfn(kvm_pfn_t pfn);
 
 struct kvm_irq_ack_notifier {
 	struct hlist_node link;

virt/kvm/kvm_main.c +23 -3

index e7a07132cd7f..0dac149ead16 100644
@@ -149,10 +149,30 @@ __weak int kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
 	return 0;
 }
 
+bool kvm_is_zone_device_pfn(kvm_pfn_t pfn)
+{
+	/*
+	 * The metadata used by is_zone_device_page() to determine whether or
+	 * not a page is ZONE_DEVICE is guaranteed to be valid if and only if
+	 * the device has been pinned, e.g. by get_user_pages().  WARN if the
+	 * page_count() is zero to help detect bad usage of this helper.
+	 */
+	if (!pfn_valid(pfn) || WARN_ON_ONCE(!page_count(pfn_to_page(pfn))))
+		return false;
+
+	return is_zone_device_page(pfn_to_page(pfn));
+}
+
 bool kvm_is_reserved_pfn(kvm_pfn_t pfn)
 {
+	/*
+	 * ZONE_DEVICE pages currently set PG_reserved, but from a refcounting
+	 * perspective they are "normal" pages, albeit with slightly different
+	 * usage rules.
+	 */
 	if (pfn_valid(pfn))
-		return PageReserved(pfn_to_page(pfn));
+		return PageReserved(pfn_to_page(pfn)) &&
+		       !kvm_is_zone_device_pfn(pfn);
 
 	return true;
 }

@@ -1857,7 +1877,7 @@ EXPORT_SYMBOL_GPL(kvm_release_pfn_dirty);
 
 void kvm_set_pfn_dirty(kvm_pfn_t pfn)
 {
-	if (!kvm_is_reserved_pfn(pfn)) {
+	if (!kvm_is_reserved_pfn(pfn) && !kvm_is_zone_device_pfn(pfn)) {
 		struct page *page = pfn_to_page(pfn);
 
 		SetPageDirty(page);

@@ -1867,7 +1887,7 @@ EXPORT_SYMBOL_GPL(kvm_set_pfn_dirty);
 
 void kvm_set_pfn_accessed(kvm_pfn_t pfn)
 {
-	if (!kvm_is_reserved_pfn(pfn))
+	if (!kvm_is_reserved_pfn(pfn) && !kvm_is_zone_device_pfn(pfn))
 		mark_page_accessed(pfn_to_page(pfn));
 }
 EXPORT_SYMBOL_GPL(kvm_set_pfn_accessed);

Sasha Levin

maintainer

2019-11-25 17:44 UTC #1 lore raw

Quoted 40 lines · On Mon, Nov 18, 2019 at 04:22:40PM +0100, [email protected] wrote:

The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From a78986aae9b2988f8493f9f65a587ee433e83bc3 Mon Sep 17 00:00:00 2001
From: Sean Christopherson <[email protected]>
Date: Mon, 11 Nov 2019 14:12:27 -0800
Subject: [PATCH] KVM: MMU: Do not treat ZONE_DEVICE pages as being reserved
Explicitly exempt ZONE_DEVICE pages from kvm_is_reserved_pfn() and instead manually handle ZONE_DEVICE on a case-by-case basis. For things like page refcounts, KVM needs to treat ZONE_DEVICE pages like normal pages, e.g. put pages grabbed via gup(). But for flows such as setting A/D bits or shifting refcounts for transparent huge pages, KVM needs to to avoid processing ZONE_DEVICE pages as the flows in question lack the underlying machinery for proper handling of ZONE_DEVICE pages.
This fixes a hang reported by Adam Borowski[*] in dev_pagemap_cleanup() when running a KVM guest backed with /dev/dax memory, as KVM straight up doesn't put any references to ZONE_DEVICE pages acquired by gup().
Note, Dan Williams proposed an alternative solution of doing put_page() on ZONE_DEVICE pages immediately after gup() in order to simplify the auditing needed to ensure is_zone_device_page() is called if and only if the backing device is pinned (via gup()). But that approach would break kvm_vcpu_{un}map() as KVM requires the page to be pinned from map() 'til unmap() when accessing guest memory, unlike KVM's secondary MMU, which coordinates with mmu_notifier invalidations to avoid creating stale page references, i.e. doesn't rely on pages being pinned.
[*] http://lkml.kernel.org/r/[email protected]

Quoted 7 lines

Reported-by Adam Borowski <[email protected]>
Analyzed-by David Hildenbrand <[email protected]>
Acked-by Dan Williams <[email protected]>
Cc [email protected]
Fixes 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by Sean Christopherson <[email protected]>
Signed-off-by Paolo Bonzini <[email protected]>

I also took e7912386ede8 ("KVM: x86: reintroduce pte_list_remove, but including mmu_spte_clear_track_bits") and queued both for 4.19-4.9.

Signature · 2 lines

Thanks,
Sasha

Sean Christopherson

2019-11-25 18:01 UTC #2 lore raw

Quoted 49 lines · Sasha Levin

Quoted 40 lines · On Mon, Nov 18, 2019 at 04:22:40PM +0100, [email protected] wrote:
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From a78986aae9b2988f8493f9f65a587ee433e83bc3 Mon Sep 17 00:00:00 2001
From: Sean Christopherson <[email protected]>
Date: Mon, 11 Nov 2019 14:12:27 -0800
Subject: [PATCH] KVM: MMU: Do not treat ZONE_DEVICE pages as being reserved
Explicitly exempt ZONE_DEVICE pages from kvm_is_reserved_pfn() and instead manually handle ZONE_DEVICE on a case-by-case basis. For things like page refcounts, KVM needs to treat ZONE_DEVICE pages like normal pages, e.g. put pages grabbed via gup(). But for flows such as setting A/D bits or shifting refcounts for transparent huge pages, KVM needs to to avoid processing ZONE_DEVICE pages as the flows in question lack the underlying machinery for proper handling of ZONE_DEVICE pages.
This fixes a hang reported by Adam Borowski[*] in dev_pagemap_cleanup() when running a KVM guest backed with /dev/dax memory, as KVM straight up doesn't put any references to ZONE_DEVICE pages acquired by gup().
Note, Dan Williams proposed an alternative solution of doing put_page() on ZONE_DEVICE pages immediately after gup() in order to simplify the auditing needed to ensure is_zone_device_page() is called if and only if the backing device is pinned (via gup()). But that approach would break kvm_vcpu_{un}map() as KVM requires the page to be pinned from map() 'til unmap() when accessing guest memory, unlike KVM's secondary MMU, which coordinates with mmu_notifier invalidations to avoid creating stale page references, i.e. doesn't rely on pages being pinned.
[*] http://lkml.kernel.org/r/[email protected]
Quoted 7 lines
Reported-by Adam Borowski <[email protected]>
Analyzed-by David Hildenbrand <[email protected]>
Acked-by Dan Williams <[email protected]>
Cc [email protected]
Fixes 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by Sean Christopherson <[email protected]>
Signed-off-by Paolo Bonzini <[email protected]>

Quoted 2 lines

I also took e7912386ede8 ("KVM: x86: reintroduce pte_list_remove, but including mmu_spte_clear_track_bits") and queued both for 4.19-4.9.

I don't think that will work, you'd also have to pull in commit 8daf346226b2 ("KVM: x86: rename pte_list_remove to __pte_list_remove"). And e7912386ede8 in particular isn't stable material.

I'll send a proper backport for 4.19 and earlier, the conflicts should be easy to resolve.

Sean Christopherson

2019-11-25 18:34 UTC #3 lore raw

Quoted 4 lines · Sean Christopherson

Quoted 3 lines · Sasha Levin
Quoted 2 lines · On Mon, Nov 18, 2019 at 04:22:40PM +0100, [email protected] wrote:
The patch below does not apply to the 4.19-stable tree.

...

Quoted 11 lines

Quoted 10 lines
Quoted 7 lines
Reported-by Adam Borowski <[email protected]>
Analyzed-by David Hildenbrand <[email protected]>
Acked-by Dan Williams <[email protected]>
Cc [email protected]
Fixes 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by Sean Christopherson <[email protected]>
Signed-off-by Paolo Bonzini <[email protected]>
I also took e7912386ede8 ("KVM: x86: reintroduce pte_list_remove, but including mmu_spte_clear_track_bits") and queued both for 4.19-4.9.

Quoted 6 lines

I don't think that will work, you'd also have to pull in commit 8daf346226b2 ("KVM: x86: rename pte_list_remove to __pte_list_remove"). And e7912386ede8 in particular isn't stable material.
I'll send a proper backport for 4.19 and earlier, the conflicts should be easy to resolve.

I have a silly backporting question regarding SOBs. Should I add a second SOB for myself, reorder the SOBs, or leave it as is? E.g. (A) is the most correct from a chronological handling perspective, but having two SOBs feels weird.

Option A:

Fixes 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")

Signed-off-by Sean Christopherson <[email protected]>

Signed-off-by Paolo Bonzini <[email protected]>

[sean: backport to 4.x; resolve conflict in mmu.c]

Signed-off-by Sean Christopherson <[email protected]>

Option B:

Fixes 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")

Signed-off-by Paolo Bonzini <[email protected]>

[sean: backport to 4.x; resolve conflict in mmu.c]

Signed-off-by Sean Christopherson <[email protected]>

Option C:

Fixes 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")

Signed-off-by Sean Christopherson <[email protected]>

Signed-off-by Paolo Bonzini <[email protected]>

Greg KH

author maintainer

2019-11-25 18:41 UTC #4 lore raw

Quoted 44 lines · Sean Christopherson

Quoted 4 lines · Sean Christopherson
Quoted 3 lines · Sasha Levin
Quoted 2 lines · On Mon, Nov 18, 2019 at 04:22:40PM +0100, [email protected] wrote:
The patch below does not apply to the 4.19-stable tree.
...
Quoted 11 lines
Quoted 10 lines
Quoted 7 lines
Reported-by Adam Borowski <[email protected]>
Analyzed-by David Hildenbrand <[email protected]>
Acked-by Dan Williams <[email protected]>
Cc [email protected]
Fixes 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by Sean Christopherson <[email protected]>
Signed-off-by Paolo Bonzini <[email protected]>
I also took e7912386ede8 ("KVM: x86: reintroduce pte_list_remove, but including mmu_spte_clear_track_bits") and queued both for 4.19-4.9.
Quoted 6 lines
I don't think that will work, you'd also have to pull in commit 8daf346226b2 ("KVM: x86: rename pte_list_remove to __pte_list_remove"). And e7912386ede8 in particular isn't stable material.
I'll send a proper backport for 4.19 and earlier, the conflicts should be easy to resolve.
I have a silly backporting question regarding SOBs. Should I add a second SOB for myself, reorder the SOBs, or leave it as is? E.g. (A) is the most correct from a chronological handling perspective, but having two SOBs feels weird.
Option A:
Fixes 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by Sean Christopherson <[email protected]>
Signed-off-by Paolo Bonzini <[email protected]>
[sean: backport to 4.x; resolve conflict in mmu.c]
Signed-off-by Sean Christopherson <[email protected]>
Option B:
Fixes 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by Paolo Bonzini <[email protected]>
[sean: backport to 4.x; resolve conflict in mmu.c]
Signed-off-by Sean Christopherson <[email protected]>

Quoted 4 lines

Option C:
Fixes 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by Sean Christopherson <[email protected]>
Signed-off-by Paolo Bonzini <[email protected]>

I really do not care, what ever one you want to do :)

Sometimes A or B is usually a bit nicer to give some context as to what you did.

thanks,

greg k-h