From: Greg Kroah-Hartman Date: Mon, 11 Apr 2022 07:40:11 +0000 (+0200) Subject: 4.19-stable patches X-Git-Tag: v4.9.310~88 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=9f11a27fbc01f0f67987b94d8e20be9a73e388b1;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch mmc-renesas_sdhi-don-t-overwrite-tap-settings-when-hs400-tuning-is-complete.patch mmmremap.c-avoid-pointless-invalidate_range_start-end-on-mremap-old_size-0.patch revert-mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch --- diff --git a/queue-4.19/mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch b/queue-4.19/mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch new file mode 100644 index 00000000000..13b6053d556 --- /dev/null +++ b/queue-4.19/mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch @@ -0,0 +1,51 @@ +From 4ad099559b00ac01c3726e5c95dc3108ef47d03e Mon Sep 17 00:00:00 2001 +From: Miaohe Lin +Date: Fri, 8 Apr 2022 13:09:07 -0700 +Subject: mm/mempolicy: fix mpol_new leak in shared_policy_replace + +From: Miaohe Lin + +commit 4ad099559b00ac01c3726e5c95dc3108ef47d03e upstream. + +If mpol_new is allocated but not used in restart loop, mpol_new will be +freed via mpol_put before returning to the caller. But refcnt is not +initialized yet, so mpol_put could not do the right things and might +leak the unused mpol_new. This would happen if mempolicy was updated on +the shared shmem file while the sp->lock has been dropped during the +memory allocation. + +This issue could be triggered easily with the below code snippet if +there are many processes doing the below work at the same time: + + shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT); + shm = shmat(shmid, 0, 0); + loop many times { + mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0); + mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask, + maxnode, 0); + } + +Link: https://lkml.kernel.org/r/20220329111416.27954-1-linmiaohe@huawei.com +Fixes: 42288fe366c4 ("mm: mempolicy: Convert shared_policy mutex to spinlock") +Signed-off-by: Miaohe Lin +Acked-by: Michal Hocko +Cc: KOSAKI Motohiro +Cc: Mel Gorman +Cc: [3.8] +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/mempolicy.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/mm/mempolicy.c ++++ b/mm/mempolicy.c +@@ -2563,6 +2563,7 @@ alloc_new: + mpol_new = kmem_cache_alloc(policy_cache, GFP_KERNEL); + if (!mpol_new) + goto err_out; ++ atomic_set(&mpol_new->refcnt, 1); + goto restart; + } + diff --git a/queue-4.19/mmc-renesas_sdhi-don-t-overwrite-tap-settings-when-hs400-tuning-is-complete.patch b/queue-4.19/mmc-renesas_sdhi-don-t-overwrite-tap-settings-when-hs400-tuning-is-complete.patch new file mode 100644 index 00000000000..7dede67d95e --- /dev/null +++ b/queue-4.19/mmc-renesas_sdhi-don-t-overwrite-tap-settings-when-hs400-tuning-is-complete.patch @@ -0,0 +1,41 @@ +From 03e59b1e2f56245163b14c69e0a830c24b1a3a47 Mon Sep 17 00:00:00 2001 +From: Wolfram Sang +Date: Mon, 4 Apr 2022 13:49:02 +0200 +Subject: mmc: renesas_sdhi: don't overwrite TAP settings when HS400 tuning is complete + +From: Wolfram Sang + +commit 03e59b1e2f56245163b14c69e0a830c24b1a3a47 upstream. + +When HS400 tuning is complete and HS400 is going to be activated, we +have to keep the current number of TAPs and should not overwrite them +with a hardcoded value. This was probably a copy&paste mistake when +upporting HS400 support from the BSP. + +Fixes: 26eb2607fa28 ("mmc: renesas_sdhi: add eMMC HS400 mode support") +Reported-by: Yoshihiro Shimoda +Signed-off-by: Wolfram Sang +Reviewed-by: Yoshihiro Shimoda +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20220404114902.12175-1-wsa+renesas@sang-engineering.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/host/renesas_sdhi_core.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/mmc/host/renesas_sdhi_core.c ++++ b/drivers/mmc/host/renesas_sdhi_core.c +@@ -302,10 +302,10 @@ static void renesas_sdhi_hs400_complete( + SH_MOBILE_SDHI_SCC_TMPPORT2_HS400OSEL) | + sd_scc_read32(host, priv, SH_MOBILE_SDHI_SCC_TMPPORT2)); + +- /* Set the sampling clock selection range of HS400 mode */ + sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_DTCNTL, + SH_MOBILE_SDHI_SCC_DTCNTL_TAPEN | +- 0x4 << SH_MOBILE_SDHI_SCC_DTCNTL_TAPNUM_SHIFT); ++ sd_scc_read32(host, priv, ++ SH_MOBILE_SDHI_SCC_DTCNTL)); + + + if (host->pdata->flags & TMIO_MMC_HAVE_4TAP_HS400) diff --git a/queue-4.19/mmmremap.c-avoid-pointless-invalidate_range_start-end-on-mremap-old_size-0.patch b/queue-4.19/mmmremap.c-avoid-pointless-invalidate_range_start-end-on-mremap-old_size-0.patch new file mode 100644 index 00000000000..917c780419e --- /dev/null +++ b/queue-4.19/mmmremap.c-avoid-pointless-invalidate_range_start-end-on-mremap-old_size-0.patch @@ -0,0 +1,45 @@ +From 01e67e04c28170c47700c2c226d732bbfedb1ad0 Mon Sep 17 00:00:00 2001 +From: Paolo Bonzini +Date: Fri, 8 Apr 2022 13:09:04 -0700 +Subject: mmmremap.c: avoid pointless invalidate_range_start/end on mremap(old_size=0) + +From: Paolo Bonzini + +commit 01e67e04c28170c47700c2c226d732bbfedb1ad0 upstream. + +If an mremap() syscall with old_size=0 ends up in move_page_tables(), it +will call invalidate_range_start()/invalidate_range_end() unnecessarily, +i.e. with an empty range. + +This causes a WARN in KVM's mmu_notifier. In the past, empty ranges +have been diagnosed to be off-by-one bugs, hence the WARNing. Given the +low (so far) number of unique reports, the benefits of detecting more +buggy callers seem to outweigh the cost of having to fix cases such as +this one, where userspace is doing something silly. In this particular +case, an early return from move_page_tables() is enough to fix the +issue. + +Link: https://lkml.kernel.org/r/20220329173155.172439-1-pbonzini@redhat.com +Reported-by: syzbot+6bde52d89cfdf9f61425@syzkaller.appspotmail.com +Signed-off-by: Paolo Bonzini +Cc: Sean Christopherson +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/mremap.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/mm/mremap.c ++++ b/mm/mremap.c +@@ -201,6 +201,9 @@ unsigned long move_page_tables(struct vm + unsigned long mmun_start; /* For mmu_notifiers */ + unsigned long mmun_end; /* For mmu_notifiers */ + ++ if (!len) ++ return 0; ++ + old_end = old_addr + len; + flush_cache_range(vma, old_addr, old_end); + diff --git a/queue-4.19/revert-mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch b/queue-4.19/revert-mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch new file mode 100644 index 00000000000..b7db7071887 --- /dev/null +++ b/queue-4.19/revert-mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch @@ -0,0 +1,49 @@ +From 7e2646ed47542123168d43916b84b954532e5386 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Pali=20Roh=C3=A1r?= +Date: Fri, 18 Mar 2022 15:14:41 +0100 +Subject: Revert "mmc: sdhci-xenon: fix annoying 1.8V regulator warning" +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Pali Rohár + +commit 7e2646ed47542123168d43916b84b954532e5386 upstream. + +This reverts commit bb32e1987bc55ce1db400faf47d85891da3c9b9f. + +Commit 1a3ed0dc3594 ("mmc: sdhci-xenon: fix 1.8v regulator stabilization") +contains proper fix for the issue described in commit bb32e1987bc5 ("mmc: +sdhci-xenon: fix annoying 1.8V regulator warning"). + +Fixes: 8d876bf472db ("mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable") +Cc: stable@vger.kernel.org # 1a3ed0dc3594 ("mmc: sdhci-xenon: fix 1.8v regulator stabilization") +Signed-off-by: Pali Rohár +Reviewed-by: Marek Behún +Reviewed-by: Marcin Wojtas +Link: https://lore.kernel.org/r/20220318141441.32329-1-pali@kernel.org +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/host/sdhci-xenon.c | 10 ---------- + 1 file changed, 10 deletions(-) + +--- a/drivers/mmc/host/sdhci-xenon.c ++++ b/drivers/mmc/host/sdhci-xenon.c +@@ -243,16 +243,6 @@ static void xenon_voltage_switch(struct + { + /* Wait for 5ms after set 1.8V signal enable bit */ + usleep_range(5000, 5500); +- +- /* +- * For some reason the controller's Host Control2 register reports +- * the bit representing 1.8V signaling as 0 when read after it was +- * written as 1. Subsequent read reports 1. +- * +- * Since this may cause some issues, do an empty read of the Host +- * Control2 register here to circumvent this. +- */ +- sdhci_readw(host, SDHCI_HOST_CONTROL2); + } + + static const struct sdhci_ops sdhci_xenon_ops = { diff --git a/queue-4.19/series b/queue-4.19/series index 5dac328addb..e7edce8c767 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -311,3 +311,7 @@ rxrpc-fix-a-race-in-rxrpc_exit_net.patch qede-confirm-skb-is-allocated-before-using.patch spi-bcm-qspi-fix-mspi-only-access-with-bcm_qspi_exec.patch drbd-fix-five-use-after-free-bugs-in-get_initial_sta.patch +revert-mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch +mmc-renesas_sdhi-don-t-overwrite-tap-settings-when-hs400-tuning-is-complete.patch +mmmremap.c-avoid-pointless-invalidate_range_start-end-on-mremap-old_size-0.patch +mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch