Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Claudio Imbrenda" <imbrenda@linux.ibm.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v3 07/10] KVM: s390: Lock pte when making page secure
Date: Tue, 02 Jun 2026 14:44:06 +0000	[thread overview]
Message-ID: <20260602144406.CD0981F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260602142356.169458-8-imbrenda@linux.ibm.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] If try_get_locked_pte returns NULL for a THP, the host PTE lock is bypassed. A concurrent split of the THP allows freezing the folio without the PTE lock, reintroducing the GUP race the patch intended to fix.

Pre-existing issues:
- [High] Host kernel panic when a PV guest attempts to secure memory backed by raw PFNs (e.g., PFNMAP/VFIO without a struct page).
--

commit aa4d37eba4327b04312028eb0cda26ab49b2e88f
Author: Claudio Imbrenda <imbrenda@linux.ibm.com>

KVM: s390: Lock pte when making page secure

This commit attempts to fix a race with GUP when freezing folios during the
secure page import process by temporarily locking the PTE.

> diff --git a/arch/s390/kvm/pv.c b/arch/s390/kvm/pv.c
> index c2dafd812a3b2..4b865e75351c1 100644
> --- a/arch/s390/kvm/pv.c
> +++ b/arch/s390/kvm/pv.c

[ ... ]

> @@ -103,9 +105,21 @@ static void _kvm_s390_pv_make_secure(struct guest_fault *f)
>  {
>  	struct pv_make_secure *priv = f->priv;
>  	struct folio *folio;
> +	spinlock_t *ptl;	/* pte lock from try_get_locked_pte() */
> +	pte_t *ptep;
>  
>  	folio = pfn_folio(f->pfn);

[Severity: High]
This is a pre-existing issue, but can this cause a host kernel panic if the
guest attempts to secure memory backed by raw PFNs (e.g., PFNMAP/VFIO)
that lack a struct page?

If kvm_s390_faultin_gfn() resolves the GFN to a raw PFN but leaves
f->page = NULL, blindly converting it via pfn_folio() accesses memory
outside the bounds of the vmemmap array, returning a garbage pointer.

Later in __kvm_s390_pv_make_secure(), the code does:

    if (!f->page)
        folio_get(folio);

Would this try to increment the reference count of that garbage pointer?

>  	priv->rc = -EAGAIN;
> +
> +	if (!mmap_read_trylock(priv->kvm->mm))
> +		return;
> +
> +	ptep = try_get_locked_pte(priv->kvm->mm, gfn_to_hva(priv->kvm, f->gfn), &ptl);
> +	if (IS_ERR_VALUE(ptep)) {

[Severity: High]
Since try_get_locked_pte() returns NULL for large PMDs (THPs) or unmapped
entries, and IS_ERR_VALUE(NULL) evaluates to false, does this proceed
with ptep == NULL and no PTE lock?

If the memory is a THP and a concurrent operation triggers a THP split
immediately after try_get_locked_pte() returns NULL, the THP becomes
order-0 folios. The KVM thread then successfully locks the newly-split
order-0 folio and freezes it since it bypassed the PTE lock entirely.

Could a concurrent slow GUP on the same address then acquire the PTE lock,
read the PTE, and call try_grab_folio(), triggering a WARN_ON_ONCE because
the folio refcount is 0?

> +		priv->rc = PTR_ERR(ptep);
> +		goto out;
> +	}
> +
>  	if (folio_trylock(folio)) {
>  		priv->rc = __kvm_s390_pv_make_secure(f, folio);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260602142356.169458-1-imbrenda@linux.ibm.com?part=7

  reply	other threads:[~2026-06-02 14:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-02 14:23 [PATCH v3 00/10] KVM: s390: More gmap and vsie fixes Claudio Imbrenda
2026-06-02 14:23 ` [PATCH v3 01/10] KVM: s390: Fix _gmap_unmap_crste() Claudio Imbrenda
2026-06-02 14:23 ` [PATCH v3 02/10] KVM: s390: Fix _gmap_crstep_xchg_atomic() Claudio Imbrenda
2026-06-02 14:23 ` [PATCH v3 03/10] KVM: s390: Avoid potentially sleeping while atomic when zapping pages Claudio Imbrenda
2026-06-02 14:23 ` [PATCH v3 04/10] KVM: s390: Fix guest / virtual address confusion in _essa_clear_cbrl() Claudio Imbrenda
2026-06-02 14:23 ` [PATCH v3 05/10] KVM: s390: vsie: Fix rmap handling in _do_shadow_crste() Claudio Imbrenda
2026-06-02 14:23 ` [PATCH v3 06/10] KVM: s390: Fix fault-in code Claudio Imbrenda
2026-06-02 14:23 ` [PATCH v3 07/10] KVM: s390: Lock pte when making page secure Claudio Imbrenda
2026-06-02 14:44   ` sashiko-bot [this message]
2026-06-02 14:23 ` [PATCH v3 08/10] KVM: s390: Prevent memslots outside the ASCE range Claudio Imbrenda
2026-06-02 14:40   ` sashiko-bot
2026-06-02 14:23 ` [PATCH v3 09/10] KVM: s390: Fix possible reference leak in fault-in code Claudio Imbrenda
2026-06-02 14:23 ` [PATCH v3 10/10] KVM: s390: Remove ptep_zap_softleaf_entry() Claudio Imbrenda

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=20260602144406.CD0981F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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