From: Greg Kroah-Hartman Date: Wed, 6 Nov 2024 07:23:15 +0000 (+0100) Subject: 6.6-stable patches X-Git-Tag: v4.19.323~35 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=50c71ff05317c7c708e891443ad9b409af6a17ed;p=thirdparty%2Fkernel%2Fstable-queue.git 6.6-stable patches added patches: mm-don-t-install-pmd-mappings-when-thps-are-disabled-by-the-hw-process-vma.patch mm-huge_memory-add-vma_thp_disabled-and-thp_disabled_by_hw.patch wifi-iwlwifi-mvm-fix-6-ghz-scan-construction.patch --- diff --git a/queue-6.6/mm-don-t-install-pmd-mappings-when-thps-are-disabled-by-the-hw-process-vma.patch b/queue-6.6/mm-don-t-install-pmd-mappings-when-thps-are-disabled-by-the-hw-process-vma.patch new file mode 100644 index 00000000000..e958cdb3759 --- /dev/null +++ b/queue-6.6/mm-don-t-install-pmd-mappings-when-thps-are-disabled-by-the-hw-process-vma.patch @@ -0,0 +1,71 @@ +From 2b0f922323ccfa76219bcaacd35cd50aeaa13592 Mon Sep 17 00:00:00 2001 +From: David Hildenbrand +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 + +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 +Reported-by: Leo Fu +Tested-by: Thomas Huth +Cc: Thomas Huth +Cc: Matthew Wilcox (Oracle) +Cc: Ryan Roberts +Cc: Christian Borntraeger +Cc: Janosch Frank +Cc: Claudio Imbrenda +Cc: Hugh Dickins +Cc: Kefeng Wang +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: David Hildenbrand +Signed-off-by: Greg Kroah-Hartman +--- + 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; + diff --git a/queue-6.6/mm-huge_memory-add-vma_thp_disabled-and-thp_disabled_by_hw.patch b/queue-6.6/mm-huge_memory-add-vma_thp_disabled-and-thp_disabled_by_hw.patch new file mode 100644 index 00000000000..21462d6b1ac --- /dev/null +++ b/queue-6.6/mm-huge_memory-add-vma_thp_disabled-and-thp_disabled_by_hw.patch @@ -0,0 +1,108 @@ +From 963756aac1f011d904ddd9548ae82286d3a91f96 Mon Sep 17 00:00:00 2001 +From: Kefeng Wang +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 + +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 +Signed-off-by: David Hildenbrand +Reported-by: Leo Fu +Tested-by: Thomas Huth +Reviewed-by: Ryan Roberts +Cc: Boqiao Fu +Cc: Christian Borntraeger +Cc: Claudio Imbrenda +Cc: Hugh Dickins +Cc: Janosch Frank +Cc: Matthew Wilcox +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: David Hildenbrand +Signed-off-by: Greg Kroah-Hartman +--- + 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<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. */ diff --git a/queue-6.6/series b/queue-6.6/series index 82a1302df86..4346d9eceae 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -139,3 +139,6 @@ arm64-dts-imx8ulp-correct-the-flexspi-compatible-string.patch 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 diff --git a/queue-6.6/wifi-iwlwifi-mvm-fix-6-ghz-scan-construction.patch b/queue-6.6/wifi-iwlwifi-mvm-fix-6-ghz-scan-construction.patch new file mode 100644 index 00000000000..20d9be5fda1 --- /dev/null +++ b/queue-6.6/wifi-iwlwifi-mvm-fix-6-ghz-scan-construction.patch @@ -0,0 +1,46 @@ +From 7245012f0f496162dd95d888ed2ceb5a35170f1a Mon Sep 17 00:00:00 2001 +From: Johannes Berg +Date: Wed, 23 Oct 2024 09:17:44 +0200 +Subject: wifi: iwlwifi: mvm: fix 6 GHz scan construction + +From: Johannes Berg + +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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;