From: David Hildenbrand <david@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org, kvm@vger.kernel.org,
David Hildenbrand <david@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Hugh Dickins <hughd@google.com>, Thomas Huth <thuth@redhat.com>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Ryan Roberts <ryan.roberts@arm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Janosch Frank <frankja@linux.ibm.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
Kefeng Wang <wangkefeng.wang@huawei.com>
Subject: [PATCH v1 0/2] mm: don't install PMD mappings when THPs are disabled by the hw/process/vma
Date: Fri, 11 Oct 2024 12:24:43 +0200 [thread overview]
Message-ID: <20241011102445.934409-1-david@redhat.com> (raw)
During testing, it was found that we can get PMD mappings in processes
where THP (and more precisely, PMD mappings) are supposed to be disabled.
While it works as expected for anon+shmem, the pagecache is the problematic
bit.
For s390 KVM this currently means that a VM backed by a file located on
filesystem with large folio support can crash when KVM tries accessing
the problematic page, because the readahead logic might decide to use
a PMD-sized THP and faulting it into the page tables will install a
PMD mapping, something that s390 KVM cannot tolerate.
This might also be a problem with HW that does not support PMD mappings,
but I did not try reproducing it.
Fix it by respecting the ways to disable THPs when deciding whether we
can install a PMD mapping. khugepaged should already be taking care of
not collapsing if THPs are effectively disabled for the hw/process/vma.
An earlier patch was tested by Thomas Huth, this one still needs to
be retested; sending it out already.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Thomas Huth <thuth@redhat.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
Cc: Janosch Frank <frankja@linux.ibm.com>
Cc: Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
David Hildenbrand (1):
mm: don't install PMD mappings when THPs are disabled by the
hw/process/vma
Kefeng Wang (1):
mm: huge_memory: add vma_thp_disabled() and thp_disabled_by_hw()
include/linux/huge_mm.h | 18 ++++++++++++++++++
mm/huge_memory.c | 13 +------------
mm/memory.c | 9 +++++++++
mm/shmem.c | 7 +------
4 files changed, 29 insertions(+), 18 deletions(-)
--
2.46.1
next reply other threads:[~2024-10-11 10:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-11 10:24 David Hildenbrand [this message]
2024-10-11 10:24 ` [PATCH v1 1/2] mm: huge_memory: add vma_thp_disabled() and thp_disabled_by_hw() David Hildenbrand
2024-10-11 11:21 ` Ryan Roberts
2024-10-11 10:24 ` [PATCH v1 2/2] mm: don't install PMD mappings when THPs are disabled by the hw/process/vma David Hildenbrand
2024-10-11 11:29 ` Ryan Roberts
2024-10-11 11:33 ` David Hildenbrand
2024-10-11 11:36 ` Ryan Roberts
2024-10-11 11:40 ` David Hildenbrand
2024-10-11 11:39 ` [PATCH v1 0/2] " Thomas Huth
2024-10-11 11:43 ` 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=20241011102445.934409-1-david@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=borntraeger@linux.ibm.com \
--cc=frankja@linux.ibm.com \
--cc=hughd@google.com \
--cc=imbrenda@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ryan.roberts@arm.com \
--cc=thuth@redhat.com \
--cc=wangkefeng.wang@huawei.com \
--cc=willy@infradead.org \
/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