All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: stable@vger.kernel.org
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>, Leo Fu <bfu@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Ryan Roberts <ryan.roberts@arm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Claudio Imbrenda <imbrenda@linux.ibm.com>,
	Hugh Dickins <hughd@google.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH 6.1.y] mm: huge_memory: add vma_thp_disabled() and thp_disabled_by_hw()
Date: Tue, 22 Oct 2024 11:13:04 +0200	[thread overview]
Message-ID: <a5f10198-836e-44b6-a148-af69347dc049@redhat.com> (raw)
In-Reply-To: <20241022090018.4073306-1-david@redhat.com>

On 22.10.24 11:00, David Hildenbrand wrote:
> From: Kefeng Wang <wangkefeng.wang@huawei.com>
> 
> Patch series "mm: don't install PMD mappings when THPs are disabled by the
> hw/process/vma".
> 
> 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.
> 
> This patch (of 2):
> 
> Add vma_thp_disabled() and thp_disabled_by_hw() helpers to be shared by
> shmem_allowable_huge_orders() and __thp_vma_allowable_orders().
> 
> [david@redhat.com: rename to vma_thp_disabled(), split out thp_disabled_by_hw() ]
> Link: https://lkml.kernel.org/r/20241011102445.934409-2-david@redhat.com
> Fixes: 793917d997df ("mm/readahead: Add large folio readahead")
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> Reported-by: Leo Fu <bfu@redhat.com>
> Tested-by: Thomas Huth <thuth@redhat.com>
> Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
> Cc: Boqiao Fu <bfu@redhat.com>
> Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
> Cc: Claudio Imbrenda <imbrenda@linux.ibm.com>
> Cc: Hugh Dickins <hughd@google.com>
> Cc: Janosch Frank <frankja@linux.ibm.com>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> (cherry picked from commit 963756aac1f011d904ddd9548ae82286d3a91f96)
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> 
> Only contextual differences in shmem_allowable_huge_orders(). Note that
> this patch is required to backport the fix
> 2b0f922323ccfa76219bcaacd35cd50aeaa13592, which can be cleanly cherry
> picked on top.

ARG my backporting skills (or rather patch sending skills) are not 
strong today. This is the 6.11.y variant. Please ignore this mail ... :(

-- 
Cheers,

David / dhildenb


  reply	other threads:[~2024-10-22  9:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-18  7:57 FAILED: patch "[PATCH] mm: don't install PMD mappings when THPs are disabled by the" failed to apply to 6.1-stable tree gregkh
2024-10-21 12:24 ` David Hildenbrand
2024-10-22  9:00 ` [PATCH 6.1.y] mm: huge_memory: add vma_thp_disabled() and thp_disabled_by_hw() David Hildenbrand
2024-10-22  9:13   ` David Hildenbrand [this message]
2024-10-22  9:18 ` David Hildenbrand
2024-10-22  9:23 ` [PATCH 6.1.y] mm: don't install PMD mappings when THPs are disabled by the hw/process/vma 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=a5f10198-836e-44b6-a148-af69347dc049@redhat.com \
    --to=david@redhat.com \
    --cc=bfu@redhat.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=frankja@linux.ibm.com \
    --cc=hughd@google.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=ryan.roberts@arm.com \
    --cc=stable@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.