public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Claudio Imbrenda <imbrenda@linux.ibm.com>
To: pbonzini@redhat.com
Cc: kvm@vger.kernel.org, linux-s390@vger.kernel.org,
	frankja@linux.ibm.com, borntraeger@de.ibm.com, david@redhat.com
Subject: [GIT PULL v2 01/20] KVM: s390: vsie: fix some corner-cases when grabbing vsie pages
Date: Fri, 31 Jan 2025 12:24:51 +0100	[thread overview]
Message-ID: <20250131112510.48531-2-imbrenda@linux.ibm.com> (raw)
In-Reply-To: <20250131112510.48531-1-imbrenda@linux.ibm.com>

From: David Hildenbrand <david@redhat.com>

We try to reuse the same vsie page when re-executing the vsie with a
given SCB address. The result is that we use the same shadow SCB --
residing in the vsie page -- and can avoid flushing the TLB when
re-running the vsie on a CPU.

So, when we allocate a fresh vsie page, or when we reuse a vsie page for
a different SCB address -- reusing the shadow SCB in different context --
we set ihcpu=0xffff to trigger the flush.

However, after we looked up the SCB address in the radix tree, but before
we grabbed the vsie page by raising the refcount to 2, someone could reuse
the vsie page for a different SCB address, adjusting page->index and the
radix tree. In that case, we would be reusing the vsie page with a
wrong page->index.

Another corner case is that we might set the SCB address for a vsie
page, but fail the insertion into the radix tree. Whoever would reuse
that page would remove the corresponding radix tree entry -- which might
now be a valid entry pointing at another page, resulting in the wrong
vsie page getting removed from the radix tree.

Let's handle such races better, by validating that the SCB address of a
vsie page didn't change after we grabbed it (not reuse for a different
SCB; the alternative would be performing another tree lookup), and by
setting the SCB address to invalid until the insertion in the tree
succeeded (SCB addresses are aligned to 512, so ULONG_MAX is invalid).

These scenarios are rare, the effects a bit unclear, and these issues were
only found by code inspection. Let's CC stable to be safe.

Fixes: a3508fbe9dc6 ("KVM: s390: vsie: initial support for nested virtualization")
Cc: stable@vger.kernel.org
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Reviewed-by: Christoph Schlameuss <schlameuss@linux.ibm.com>
Tested-by: Christoph Schlameuss <schlameuss@linux.ibm.com>
Message-ID: <20250107154344.1003072-2-david@redhat.com>
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
---
 arch/s390/kvm/vsie.c | 25 +++++++++++++++++++------
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
index a687695d8f68..513e608567cc 100644
--- a/arch/s390/kvm/vsie.c
+++ b/arch/s390/kvm/vsie.c
@@ -1362,8 +1362,14 @@ static struct vsie_page *get_vsie_page(struct kvm *kvm, unsigned long addr)
 	page = radix_tree_lookup(&kvm->arch.vsie.addr_to_page, addr >> 9);
 	rcu_read_unlock();
 	if (page) {
-		if (page_ref_inc_return(page) == 2)
-			return page_to_virt(page);
+		if (page_ref_inc_return(page) == 2) {
+			if (page->index == addr)
+				return page_to_virt(page);
+			/*
+			 * We raced with someone reusing + putting this vsie
+			 * page before we grabbed it.
+			 */
+		}
 		page_ref_dec(page);
 	}
 
@@ -1393,15 +1399,20 @@ static struct vsie_page *get_vsie_page(struct kvm *kvm, unsigned long addr)
 			kvm->arch.vsie.next++;
 			kvm->arch.vsie.next %= nr_vcpus;
 		}
-		radix_tree_delete(&kvm->arch.vsie.addr_to_page, page->index >> 9);
+		if (page->index != ULONG_MAX)
+			radix_tree_delete(&kvm->arch.vsie.addr_to_page,
+					  page->index >> 9);
 	}
-	page->index = addr;
-	/* double use of the same address */
+	/* Mark it as invalid until it resides in the tree. */
+	page->index = ULONG_MAX;
+
+	/* Double use of the same address or allocation failure. */
 	if (radix_tree_insert(&kvm->arch.vsie.addr_to_page, addr >> 9, page)) {
 		page_ref_dec(page);
 		mutex_unlock(&kvm->arch.vsie.mutex);
 		return NULL;
 	}
+	page->index = addr;
 	mutex_unlock(&kvm->arch.vsie.mutex);
 
 	vsie_page = page_to_virt(page);
@@ -1496,7 +1507,9 @@ void kvm_s390_vsie_destroy(struct kvm *kvm)
 		vsie_page = page_to_virt(page);
 		release_gmap_shadow(vsie_page);
 		/* free the radix tree entry */
-		radix_tree_delete(&kvm->arch.vsie.addr_to_page, page->index >> 9);
+		if (page->index != ULONG_MAX)
+			radix_tree_delete(&kvm->arch.vsie.addr_to_page,
+					  page->index >> 9);
 		__free_page(page);
 	}
 	kvm->arch.vsie.page_count = 0;
-- 
2.48.1


  reply	other threads:[~2025-01-31 11:25 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-31 11:24 [GIT PULL v2 00/20] KVM: s390: some non-trivial fixes and cleanups for 6.14 Claudio Imbrenda
2025-01-31 11:24 ` Claudio Imbrenda [this message]
2025-01-31 11:24 ` [GIT PULL v2 02/20] KVM: s390: vsie: stop using page->index Claudio Imbrenda
2025-01-31 11:24 ` [GIT PULL v2 03/20] KVM: s390: vsie: stop messing with page refcount Claudio Imbrenda
2025-01-31 11:24 ` [GIT PULL v2 04/20] KVM: s390: vsie: stop using "struct page" for vsie page Claudio Imbrenda
2025-01-31 11:24 ` [GIT PULL v2 05/20] KVM: Do not restrict the size of KVM-internal memory regions Claudio Imbrenda
2025-01-31 11:24 ` [GIT PULL v2 06/20] KVM: s390: wrapper for KVM_BUG Claudio Imbrenda
2025-01-31 11:24 ` [GIT PULL v2 07/20] KVM: s390: fake memslot for ucontrol VMs Claudio Imbrenda
2025-01-31 11:24 ` [GIT PULL v2 08/20] KVM: s390: selftests: fix ucontrol memory region test Claudio Imbrenda
2025-01-31 11:24 ` [GIT PULL v2 09/20] KVM: s390: move pv gmap functions into kvm Claudio Imbrenda
2025-02-12 16:55   ` David Hildenbrand
2025-02-12 17:45     ` Claudio Imbrenda
2025-02-12 18:14       ` David Hildenbrand
2025-02-13 10:02         ` David Hildenbrand
2025-01-31 11:25 ` [GIT PULL v2 10/20] KVM: s390: use __kvm_faultin_pfn() Claudio Imbrenda
2025-01-31 11:25 ` [GIT PULL v2 11/20] KVM: s390: get rid of gmap_fault() Claudio Imbrenda
2025-01-31 11:25 ` [GIT PULL v2 12/20] KVM: s390: get rid of gmap_translate() Claudio Imbrenda
2025-01-31 11:25 ` [GIT PULL v2 13/20] KVM: s390: move some gmap shadowing functions away from mm/gmap.c Claudio Imbrenda
2025-01-31 11:25 ` [GIT PULL v2 14/20] KVM: s390: stop using page->index for non-shadow gmaps Claudio Imbrenda
2025-01-31 11:25 ` [GIT PULL v2 15/20] KVM: s390: stop using lists to keep track of used dat tables Claudio Imbrenda
2025-01-31 11:25 ` [GIT PULL v2 16/20] KVM: s390: move gmap_shadow_pgt_lookup() into kvm Claudio Imbrenda
2025-01-31 11:25 ` [GIT PULL v2 17/20] KVM: s390: remove useless page->index usage Claudio Imbrenda
2025-01-31 11:25 ` [GIT PULL v2 18/20] KVM: s390: move PGSTE softbits Claudio Imbrenda
2025-01-31 11:25 ` [GIT PULL v2 19/20] KVM: s390: remove the last user of page->index Claudio Imbrenda
2025-01-31 11:25 ` [GIT PULL v2 20/20] KVM: s390: selftests: Streamline uc_skey test to issue iske after sske Claudio Imbrenda
2025-02-06  9:39 ` [GIT PULL v2 00/20] KVM: s390: some non-trivial fixes and cleanups for 6.14 Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250131112510.48531-2-imbrenda@linux.ibm.com \
    --to=imbrenda@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox