--- /dev/null
+From 2b0f922323ccfa76219bcaacd35cd50aeaa13592 Mon Sep 17 00:00:00 2001
+From: David Hildenbrand <david@redhat.com>
+Date: Fri, 11 Oct 2024 12:24:45 +0200
+Subject: mm: don't install PMD mappings when THPs are disabled by the hw/process/vma
+
+From: David Hildenbrand <david@redhat.com>
+
+commit 2b0f922323ccfa76219bcaacd35cd50aeaa13592 upstream.
+
+We (or rather, readahead logic :) ) might be allocating a THP in the
+pagecache and then try mapping it into a process that explicitly disabled
+THP: we might end up installing PMD mappings.
+
+This is a problem for s390x KVM, which explicitly remaps all PMD-mapped
+THPs to be PTE-mapped in s390_enable_sie()->thp_split_mm(), before
+starting the VM.
+
+For example, starting a VM backed on a file system with large folios
+supported makes the VM crash when the VM tries accessing such a mapping
+using KVM.
+
+Is it also a problem when the HW disabled THP using
+TRANSPARENT_HUGEPAGE_UNSUPPORTED? At least on x86 this would be the case
+without X86_FEATURE_PSE.
+
+In the future, we might be able to do better on s390x and only disallow
+PMD mappings -- what s390x and likely TRANSPARENT_HUGEPAGE_UNSUPPORTED
+really wants. For now, fix it by essentially performing the same check as
+would be done in __thp_vma_allowable_orders() or in shmem code, where this
+works as expected, and disallow PMD mappings, making us fallback to PTE
+mappings.
+
+Link: https://lkml.kernel.org/r/20241011102445.934409-3-david@redhat.com
+Fixes: 793917d997df ("mm/readahead: Add large folio readahead")
+Signed-off-by: David Hildenbrand <david@redhat.com>
+Reported-by: Leo Fu <bfu@redhat.com>
+Tested-by: Thomas Huth <thuth@redhat.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: Hugh Dickins <hughd@google.com>
+Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: David Hildenbrand <david@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/memory.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/mm/memory.c
++++ b/mm/memory.c
+@@ -4293,6 +4293,15 @@ vm_fault_t do_set_pmd(struct vm_fault *v
+ pmd_t entry;
+ vm_fault_t ret = VM_FAULT_FALLBACK;
+
++ /*
++ * It is too late to allocate a small folio, we already have a large
++ * folio in the pagecache: especially s390 KVM cannot tolerate any
++ * PMD mappings, but PTE-mapped THP are fine. So let's simply refuse any
++ * PMD mappings if THPs are disabled.
++ */
++ if (thp_disabled_by_hw() || vma_thp_disabled(vma, vma->vm_flags))
++ return ret;
++
+ if (!transhuge_vma_suitable(vma, haddr))
+ return ret;
+
--- /dev/null
+From 963756aac1f011d904ddd9548ae82286d3a91f96 Mon Sep 17 00:00:00 2001
+From: Kefeng Wang <wangkefeng.wang@huawei.com>
+Date: Fri, 11 Oct 2024 12:24:44 +0200
+Subject: mm: huge_memory: add vma_thp_disabled() and thp_disabled_by_hw()
+
+From: Kefeng Wang <wangkefeng.wang@huawei.com>
+
+commit 963756aac1f011d904ddd9548ae82286d3a91f96 upstream.
+
+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>
+Signed-off-by: David Hildenbrand <david@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/huge_mm.h | 18 ++++++++++++++++++
+ mm/huge_memory.c | 13 +------------
+ 2 files changed, 19 insertions(+), 12 deletions(-)
+
+--- a/include/linux/huge_mm.h
++++ b/include/linux/huge_mm.h
+@@ -137,6 +137,24 @@ bool hugepage_vma_check(struct vm_area_s
+ (transparent_hugepage_flags & \
+ (1<<TRANSPARENT_HUGEPAGE_USE_ZERO_PAGE_FLAG))
+
++static inline bool vma_thp_disabled(struct vm_area_struct *vma,
++ unsigned long vm_flags)
++{
++ /*
++ * Explicitly disabled through madvise or prctl, or some
++ * architectures may disable THP for some mappings, for
++ * example, s390 kvm.
++ */
++ return (vm_flags & VM_NOHUGEPAGE) ||
++ test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags);
++}
++
++static inline bool thp_disabled_by_hw(void)
++{
++ /* If the hardware/firmware marked hugepage support disabled. */
++ return transparent_hugepage_flags & (1 << TRANSPARENT_HUGEPAGE_UNSUPPORTED);
++}
++
+ unsigned long thp_get_unmapped_area(struct file *filp, unsigned long addr,
+ unsigned long len, unsigned long pgoff, unsigned long flags);
+
+--- a/mm/huge_memory.c
++++ b/mm/huge_memory.c
+@@ -78,18 +78,7 @@ bool hugepage_vma_check(struct vm_area_s
+ if (!vma->vm_mm) /* vdso */
+ return false;
+
+- /*
+- * Explicitly disabled through madvise or prctl, or some
+- * architectures may disable THP for some mappings, for
+- * example, s390 kvm.
+- * */
+- if ((vm_flags & VM_NOHUGEPAGE) ||
+- test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags))
+- return false;
+- /*
+- * If the hardware/firmware marked hugepage support disabled.
+- */
+- if (transparent_hugepage_flags & (1 << TRANSPARENT_HUGEPAGE_UNSUPPORTED))
++ if (thp_disabled_by_hw() || vma_thp_disabled(vma, vm_flags))
+ return false;
+
+ /* khugepaged doesn't collapse DAX vma, but page fault is fine. */
io_uring-always-lock-__io_cqring_overflow_flush.patch
wifi-mac80211-fix-null-dereference-at-band-check-in-starting-tx-ba-session.patch
nilfs2-fix-kernel-bug-due-to-missing-clearing-of-checked-flag.patch
+wifi-iwlwifi-mvm-fix-6-ghz-scan-construction.patch
+mm-huge_memory-add-vma_thp_disabled-and-thp_disabled_by_hw.patch
+mm-don-t-install-pmd-mappings-when-thps-are-disabled-by-the-hw-process-vma.patch
--- /dev/null
+From 7245012f0f496162dd95d888ed2ceb5a35170f1a Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Wed, 23 Oct 2024 09:17:44 +0200
+Subject: wifi: iwlwifi: mvm: fix 6 GHz scan construction
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+commit 7245012f0f496162dd95d888ed2ceb5a35170f1a upstream.
+
+If more than 255 colocated APs exist for the set of all
+APs found during 2.4/5 GHz scanning, then the 6 GHz scan
+construction will loop forever since the loop variable
+has type u8, which can never reach the number found when
+that's bigger than 255, and is stored in a u32 variable.
+Also move it into the loops to have a smaller scope.
+
+Using a u32 there is fine, we limit the number of APs in
+the scan list and each has a limit on the number of RNR
+entries due to the frame size. With a limit of 1000 scan
+results, a frame size upper bound of 4096 (really it's
+more like ~2300) and a TBTT entry size of at least 11,
+we get an upper bound for the number of ~372k, well in
+the bounds of a u32.
+
+Cc: stable@vger.kernel.org
+Fixes: eae94cf82d74 ("iwlwifi: mvm: add support for 6GHz")
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219375
+Link: https://patch.msgid.link/20241023091744.f4baed5c08a1.I8b417148bbc8c5d11c101e1b8f5bf372e17bf2a7@changeid
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
++++ b/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
+@@ -1751,7 +1751,8 @@ iwl_mvm_umac_scan_cfg_channels_v7_6g(str
+ &cp->channel_config[ch_cnt];
+
+ u32 s_ssid_bitmap = 0, bssid_bitmap = 0, flags = 0;
+- u8 j, k, s_max = 0, b_max = 0, n_used_bssid_entries;
++ u8 k, s_max = 0, b_max = 0, n_used_bssid_entries;
++ u32 j;
+ bool force_passive, found = false, allow_passive = true,
+ unsolicited_probe_on_chan = false, psc_no_listen = false;
+ s8 psd_20 = IEEE80211_RNR_TBTT_PARAMS_PSD_RESERVED;
projects / thirdparty / kernel / stable-queue.git / commitdiff
