From: sashiko-bot@kernel.org
To: "Claudio Imbrenda" <imbrenda@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, "Vasily Gorbik" <gor@linux.ibm.com>,
"Heiko Carstens" <hca@linux.ibm.com>,
kvm@vger.kernel.org, "Alexander Gordeev" <agordeev@linux.ibm.com>
Subject: Re: [GIT PULL v1 04/12] s390/mm: Fix handling of _PAGE_UNUSED pte bit
Date: Wed, 24 Jun 2026 11:42:32 +0000 [thread overview]
Message-ID: <20260624114233.30D871F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260624111928.144283-5-imbrenda@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Medium] The KVM unused page discard optimization is completely defeated by page aging.
Pre-existing issues:
- [Critical] Guest memory corruption because hardware memory access does not clear `_PAGE_UNUSED`.
--
commit 4123a9573ff29d2fd29637723b6e4e5841aed14e
Author: Claudio Imbrenda <imbrenda@linux.ibm.com>
s390/mm: Fix handling of _PAGE_UNUSED pte bit
The _PAGE_UNUSED softbit should not really be lying around. Its sole
purpose is to signal to try_to_unmap_one() and try_to_migrate_one()
that the page can be discarded instead of being moved / swapped.
> diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
> index 2c6cee8241e04..4740c75649ebb 100644
> --- a/arch/s390/include/asm/pgtable.h
> +++ b/arch/s390/include/asm/pgtable.h
> @@ -980,6 +980,8 @@ static inline void set_pmd(pmd_t *pmdp, pmd_t pmd)
>
> static inline void set_pte(pte_t *ptep, pte_t pte)
> {
> + if (pte_present(pte))
> + pte = clear_pte_bit(pte, __pgprot(_PAGE_UNUSED));
[Severity: Critical]
This is a pre-existing issue, but does moving the clearing logic into
set_pte() fully resolve the guest memory corruption?
When the guest resumes using a page, the s390 hardware transparently updates
the referenced and dirty bits in the hardware Storage Key without triggering
a host page fault. Because no software page fault occurs, set_pte() is never
invoked, leaving _PAGE_UNUSED erroneously set on the active host PTE.
If memory compaction occurs, try_to_migrate_one() checks pte_unused() and
drops the page without first validating the Storage Key:
mm/rmap.c:try_to_migrate_one() {
...
} else if (likely(pte_present(pteval)) && pte_unused(pteval) &&
!userfaultfd_armed(vma)) {
/*
* The guest indicated that the page content is of no
* interest anymore. Simply discard the pte, vmscan
* will take care of the rest.
*/
...
}
Could this lead to the silent loss of active guest data since the migration
path incorrectly assumes the page is discardable?
[Severity: Medium]
Does clearing _PAGE_UNUSED unconditionally here in set_pte() defeat the KVM
unused page discard optimization during page aging?
When the system is under memory pressure, shrink_page_list() calls
folio_referenced(), which invokes ptep_test_and_clear_young() to inspect the
Storage Key and clear the young bit.
On s390, ptep_test_and_clear_young() writes the updated PTE back via an
unconditional call to set_pte(). This would permanently destroy the
KVM-provided _PAGE_UNUSED marker.
Immediately after aging, try_to_unmap_one() checks the unused status:
mm/rmap.c:try_to_unmap_one() {
...
} else if (likely(pte_present(pteval)) && pte_unused(pteval) &&
!userfaultfd_armed(vma)) {
/*
* The guest indicated that the page content is of no
* interest anymore. Simply discard the pte
*/
...
}
Because the bit was just cleared by the aging process, won't this evaluate
to false, causing truly unused guest pages to be unnecessarily swapped out
instead of efficiently discarded?
> WRITE_ONCE(*ptep, pte);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624111928.144283-1-imbrenda@linux.ibm.com?part=4
next prev parent reply other threads:[~2026-06-24 11:42 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-24 11:19 [GIT PULL v1 00/12] KVM: s390: Fix S390_USER_OPEREXEC and more gmap fixes Claudio Imbrenda
2026-06-24 11:19 ` [GIT PULL v1 01/12] KVM: s390: Fix S390_USER_OPEREXEC enablement without STFLE 74 Claudio Imbrenda
2026-06-24 11:40 ` sashiko-bot
2026-06-24 11:19 ` [GIT PULL v1 02/12] KVM: s390: selftests: Extended user_operexec tests Claudio Imbrenda
2026-06-24 11:19 ` [GIT PULL v1 03/12] KVM: s390: Fix typo in UCONTROL documentation Claudio Imbrenda
2026-06-24 11:19 ` [GIT PULL v1 04/12] s390/mm: Fix handling of _PAGE_UNUSED pte bit Claudio Imbrenda
2026-06-24 11:42 ` sashiko-bot [this message]
2026-06-24 11:19 ` [GIT PULL v1 05/12] KVM: s390: Fix dat_peek_cmma() overflow Claudio Imbrenda
2026-06-24 11:38 ` sashiko-bot
2026-06-24 11:19 ` [GIT PULL v1 06/12] KVM: s390: Do not set special large pages dirty Claudio Imbrenda
2026-06-24 11:37 ` sashiko-bot
2026-06-24 11:19 ` [GIT PULL v1 07/12] KVM: s390: Fix code typo in gmap_protect_asce_top_level() Claudio Imbrenda
2026-06-24 11:19 ` [GIT PULL v1 08/12] KVM: s390: Fix handle_{sske,pfmf} under memory pressure Claudio Imbrenda
2026-06-24 11:19 ` [GIT PULL v1 09/12] KVM: s390: Fix locking in kvm_s390_set_mem_control() Claudio Imbrenda
2026-06-24 11:19 ` [GIT PULL v1 10/12] KVM: s390: Fix cmma dirty tracking Claudio Imbrenda
2026-06-24 11:46 ` sashiko-bot
2026-06-24 11:19 ` [GIT PULL v1 11/12] KVM: s390: selftests: Fix cmma selftest Claudio Imbrenda
2026-06-24 11:19 ` [GIT PULL v1 12/12] KVM: s390: Return failure in case of failure in kvm_s390_set_cmma_bits() 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=20260624114233.30D871F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@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