From: David Hildenbrand <david@redhat.com>
To: Claudio Imbrenda <imbrenda@linux.ibm.com>, kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
frankja@linux.ibm.com, borntraeger@de.ibm.com, nrb@linux.ibm.com,
seiden@linux.ibm.com, nsg@linux.ibm.com,
schlameuss@linux.ibm.com, hca@linux.ibm.com
Subject: Re: [PATCH v3 1/1] KVM: s390: pv: fix race when making a page secure
Date: Fri, 28 Feb 2025 22:15:04 +0100 [thread overview]
Message-ID: <370231a1-af36-46ca-a87c-ce1929473c1d@redhat.com> (raw)
In-Reply-To: <20250227130954.440821-2-imbrenda@linux.ibm.com>
On 27.02.25 14:09, Claudio Imbrenda wrote:
> Holding the pte lock for the page that is being converted to secure is
> needed to avoid races. A previous commit removed the locking, which
> caused issues. Fix by locking the pte again.
>
> Fixes: 5cbe24350b7d ("KVM: s390: move pv gmap functions into kvm")
> Reported-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Tested with shmem / memory-backend-memfd that ends up using large folios
/ THPs.
Tested-by: David Hildenbrand <david@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Two comments below.
[...]
> +
> +int make_hva_secure(struct mm_struct *mm, unsigned long hva, struct uv_cb_header *uvcb)
> +{
> + struct folio *folio;
> + spinlock_t *ptelock;
> + pte_t *ptep;
> + int rc;
> +
> + ptep = get_locked_valid_pte(mm, hva, &ptelock);
> + if (!ptep)
> + return -ENXIO;
> +
> + folio = page_folio(pte_page(*ptep));
> + folio_get(folio);
Grabbing a folio reference is only required if you want to keep using
the folio after the pte_unmap_unlock. While the PTL is locked it cannot
vanish.
So consider grabbing a reference only before dropping the PTL and you
inted to call kvm_s390_wiggle_split_folio(). Then, you would effectively
not require these two atomics on the expected hot path.
(I recall that the old code did that)
> + /*
> + * Secure pages cannot be huge and userspace should not combine both.
> + * In case userspace does it anyway this will result in an -EFAULT for
> + * the unpack. The guest is thus never reaching secure mode.
> + * If userspace plays dirty tricks and decides to map huge pages at a
> + * later point in time, it will receive a segmentation fault or
> + * KVM_RUN will return -EFAULT.
> + */
> + if (folio_test_hugetlb(folio))
> + rc = -EFAULT;
> + else if (folio_test_large(folio))
> + rc = -E2BIG;
> + else if (!pte_write(*ptep))
> + rc = -ENXIO;
> + else
> + rc = make_folio_secure(mm, folio, uvcb);
> + pte_unmap_unlock(ptep, ptelock);
> +
> + if (rc == -E2BIG || rc == -EBUSY)
> + rc = kvm_s390_wiggle_split_folio(mm, folio, rc == -E2BIG);
> + folio_put(folio);
> +
> + return rc;
> +}
> +EXPORT_SYMBOL_GPL(make_hva_secure);
>
> /*
> * To be called with the folio locked or with an extra reference! This will
> diff --git a/arch/s390/kvm/gmap.c b/arch/s390/kvm/gmap.c
> index 02adf151d4de..c08950b4301c 100644
There is one remaining reference to __gmap_make_secure, which you remove:
$ git grep __gmap_make_secure
arch/s390/kvm/gmap.c: * Return: 0 on success, < 0 in case of error (see
__gmap_make_secure()).
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2025-02-28 21:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-27 13:09 [PATCH v3 0/1] KVM: s390: fix a newly introduced bug Claudio Imbrenda
2025-02-27 13:09 ` [PATCH v3 1/1] KVM: s390: pv: fix race when making a page secure Claudio Imbrenda
2025-02-28 21:15 ` David Hildenbrand [this message]
2025-03-04 9:21 ` Claudio Imbrenda
2025-03-04 9:45 ` David Hildenbrand
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=370231a1-af36-46ca-a87c-ce1929473c1d@redhat.com \
--to=david@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=frankja@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=nrb@linux.ibm.com \
--cc=nsg@linux.ibm.com \
--cc=schlameuss@linux.ibm.com \
--cc=seiden@linux.ibm.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