From: Greg Kroah-Hartman Date: Fri, 13 May 2022 09:06:17 +0000 (+0200) Subject: 5.17-stable patches X-Git-Tag: v4.9.314~6 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=4dc4e89d504b4568ca3a2f25a594c41ed333a25e;p=thirdparty%2Fkernel%2Fstable-queue.git 5.17-stable patches added patches: mm-fix-missing-cache-flush-for-all-tail-pages-of-compound-page.patch mm-hugetlb-fix-missing-cache-flush-in-copy_huge_page_from_user.patch mm-hugetlb-fix-missing-cache-flush-in-hugetlb_mcopy_atomic_pte.patch mm-hwpoison-fix-error-page-recovered-but-reported-not-recovered.patch mm-migrate-fix-establishing-demotion-target.patch mm-mlock-fix-potential-imbalanced-rlimit-ucounts-adjustment.patch mm-shmem-fix-missing-cache-flush-in-shmem_mfill_atomic_pte.patch mm-userfaultfd-fix-missing-cache-flush-in-mcopy_atomic_pte-and-__mcopy_atomic.patch --- diff --git a/queue-5.17/mm-fix-missing-cache-flush-for-all-tail-pages-of-compound-page.patch b/queue-5.17/mm-fix-missing-cache-flush-for-all-tail-pages-of-compound-page.patch new file mode 100644 index 00000000000..78f992e4658 --- /dev/null +++ b/queue-5.17/mm-fix-missing-cache-flush-for-all-tail-pages-of-compound-page.patch @@ -0,0 +1,63 @@ +From 2771739a7162782c0aa6424b2e3dd874e884a15d Mon Sep 17 00:00:00 2001 +From: Muchun Song +Date: Tue, 22 Mar 2022 14:41:56 -0700 +Subject: mm: fix missing cache flush for all tail pages of compound page + +From: Muchun Song + +commit 2771739a7162782c0aa6424b2e3dd874e884a15d upstream. + +The D-cache maintenance inside move_to_new_page() only consider one +page, there is still D-cache maintenance issue for tail pages of +compound page (e.g. THP or HugeTLB). + +THP migration is only enabled on x86_64, ARM64 and powerpc, while +powerpc and arm64 need to maintain the consistency between I-Cache and +D-Cache, which depends on flush_dcache_page() to maintain the +consistency between I-Cache and D-Cache. + +But there is no issues on arm64 and powerpc since they already considers +the compound page cache flushing in their icache flush function. +HugeTLB migration is enabled on arm, arm64, mips, parisc, powerpc, +riscv, s390 and sh, while arm has handled the compound page cache flush +in flush_dcache_page(), but most others do not. + +In theory, the issue exists on many architectures. Fix this by not +using flush_dcache_folio() since it is not backportable. + +Link: https://lkml.kernel.org/r/20220210123058.79206-3-songmuchun@bytedance.com +Fixes: 290408d4a250 ("hugetlb: hugepage migration core") +Signed-off-by: Muchun Song +Reviewed-by: Zi Yan +Cc: Axel Rasmussen +Cc: David Rientjes +Cc: Fam Zheng +Cc: Kirill A. Shutemov +Cc: Lars Persson +Cc: Mike Kravetz +Cc: Peter Xu +Cc: Xiongchun Duan +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/migrate.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- a/mm/migrate.c ++++ b/mm/migrate.c +@@ -916,9 +916,12 @@ static int move_to_new_page(struct page + if (!PageMappingFlags(page)) + page->mapping = NULL; + +- if (likely(!is_zone_device_page(newpage))) +- flush_dcache_page(newpage); ++ if (likely(!is_zone_device_page(newpage))) { ++ int i, nr = compound_nr(newpage); + ++ for (i = 0; i < nr; i++) ++ flush_dcache_page(newpage + i); ++ } + } + out: + return rc; diff --git a/queue-5.17/mm-hugetlb-fix-missing-cache-flush-in-copy_huge_page_from_user.patch b/queue-5.17/mm-hugetlb-fix-missing-cache-flush-in-copy_huge_page_from_user.patch new file mode 100644 index 00000000000..9fb054e0ac3 --- /dev/null +++ b/queue-5.17/mm-hugetlb-fix-missing-cache-flush-in-copy_huge_page_from_user.patch @@ -0,0 +1,47 @@ +From e763243cc6cb1fcc720ec58cfd6e7c35ae90a479 Mon Sep 17 00:00:00 2001 +From: Muchun Song +Date: Tue, 22 Mar 2022 14:41:59 -0700 +Subject: mm: hugetlb: fix missing cache flush in copy_huge_page_from_user() + +From: Muchun Song + +commit e763243cc6cb1fcc720ec58cfd6e7c35ae90a479 upstream. + +userfaultfd calls copy_huge_page_from_user() which does not do any cache +flushing for the target page. Then the target page will be mapped to +the user space with a different address (user address), which might have +an alias issue with the kernel address used to copy the data from the +user to. + +Fix this issue by flushing dcache in copy_huge_page_from_user(). + +Link: https://lkml.kernel.org/r/20220210123058.79206-4-songmuchun@bytedance.com +Fixes: fa4d75c1de13 ("userfaultfd: hugetlbfs: add copy_huge_page_from_user for hugetlb userfaultfd support") +Signed-off-by: Muchun Song +Reviewed-by: Mike Kravetz +Cc: Axel Rasmussen +Cc: David Rientjes +Cc: Fam Zheng +Cc: Kirill A. Shutemov +Cc: Lars Persson +Cc: Peter Xu +Cc: Xiongchun Duan +Cc: Zi Yan +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/memory.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/mm/memory.c ++++ b/mm/memory.c +@@ -5475,6 +5475,8 @@ long copy_huge_page_from_user(struct pag + if (rc) + break; + ++ flush_dcache_page(subpage); ++ + cond_resched(); + } + return ret_val; diff --git a/queue-5.17/mm-hugetlb-fix-missing-cache-flush-in-hugetlb_mcopy_atomic_pte.patch b/queue-5.17/mm-hugetlb-fix-missing-cache-flush-in-hugetlb_mcopy_atomic_pte.patch new file mode 100644 index 00000000000..203407c3bf7 --- /dev/null +++ b/queue-5.17/mm-hugetlb-fix-missing-cache-flush-in-hugetlb_mcopy_atomic_pte.patch @@ -0,0 +1,53 @@ +From 348923665a0e50ad9fc0b3bb8127d3cb976691cc Mon Sep 17 00:00:00 2001 +From: Muchun Song +Date: Tue, 22 Mar 2022 14:42:02 -0700 +Subject: mm: hugetlb: fix missing cache flush in hugetlb_mcopy_atomic_pte() + +From: Muchun Song + +commit 348923665a0e50ad9fc0b3bb8127d3cb976691cc upstream. + +folio_copy() will copy the data from one page to the target page, then +the target page will be mapped to the user space address, which might +have an alias issue with the kernel address used to copy the data from +the page to. There are 2 ways to fix this issue. + + 1) insert flush_dcache_page() after folio_copy(). + + 2) replace folio_copy() with copy_user_huge_page() which already + considers the cache maintenance. + +We chose 2) way to fix the issue since architectures can optimize this +situation. It is also make backports easier. + +Link: https://lkml.kernel.org/r/20220210123058.79206-5-songmuchun@bytedance.com +Fixes: 8cc5fcbb5be8 ("mm, hugetlb: fix racy resv_huge_pages underflow on UFFDIO_COPY") +Signed-off-by: Muchun Song +Reviewed-by: Mike Kravetz +Cc: Axel Rasmussen +Cc: David Rientjes +Cc: Fam Zheng +Cc: Kirill A. Shutemov +Cc: Lars Persson +Cc: Peter Xu +Cc: Xiongchun Duan +Cc: Zi Yan +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/hugetlb.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/mm/hugetlb.c ++++ b/mm/hugetlb.c +@@ -5820,7 +5820,8 @@ int hugetlb_mcopy_atomic_pte(struct mm_s + *pagep = NULL; + goto out; + } +- folio_copy(page_folio(page), page_folio(*pagep)); ++ copy_user_huge_page(page, *pagep, dst_addr, dst_vma, ++ pages_per_huge_page(h)); + put_page(*pagep); + *pagep = NULL; + } diff --git a/queue-5.17/mm-hwpoison-fix-error-page-recovered-but-reported-not-recovered.patch b/queue-5.17/mm-hwpoison-fix-error-page-recovered-but-reported-not-recovered.patch new file mode 100644 index 00000000000..364f04c1568 --- /dev/null +++ b/queue-5.17/mm-hwpoison-fix-error-page-recovered-but-reported-not-recovered.patch @@ -0,0 +1,62 @@ +From 046545a661af2beec21de7b90ca0e35f05088a81 Mon Sep 17 00:00:00 2001 +From: Naoya Horiguchi +Date: Tue, 22 Mar 2022 14:44:06 -0700 +Subject: mm/hwpoison: fix error page recovered but reported "not recovered" + +From: Naoya Horiguchi + +commit 046545a661af2beec21de7b90ca0e35f05088a81 upstream. + +When an uncorrected memory error is consumed there is a race between the +CMCI from the memory controller reporting an uncorrected error with a +UCNA signature, and the core reporting and SRAR signature machine check +when the data is about to be consumed. + +If the CMCI wins that race, the page is marked poisoned when +uc_decode_notifier() calls memory_failure() and the machine check +processing code finds the page already poisoned. It calls +kill_accessing_process() to make sure a SIGBUS is sent. But returns the +wrong error code. + +Console log looks like this: + + mce: Uncorrected hardware memory error in user-access at 3710b3400 + Memory failure: 0x3710b3: recovery action for dirty LRU page: Recovered + Memory failure: 0x3710b3: already hardware poisoned + Memory failure: 0x3710b3: Sending SIGBUS to einj_mem_uc:361438 due to hardware memory corruption + mce: Memory error not recovered + +kill_accessing_process() is supposed to return -EHWPOISON to notify that +SIGBUS is already set to the process and kill_me_maybe() doesn't have to +send it again. But current code simply fails to do this, so fix it to +make sure to work as intended. This change avoids the noise message +"Memory error not recovered" and skips duplicate SIGBUSs. + +[tony.luck@intel.com: reword some parts of commit message] + +Link: https://lkml.kernel.org/r/20220113231117.1021405-1-naoya.horiguchi@linux.dev +Fixes: a3f5d80ea401 ("mm,hwpoison: send SIGBUS with error virutal address") +Signed-off-by: Naoya Horiguchi +Reported-by: Youquan Song +Cc: Tony Luck +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/memory-failure.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/mm/memory-failure.c ++++ b/mm/memory-failure.c +@@ -707,8 +707,10 @@ static int kill_accessing_process(struct + (void *)&priv); + if (ret == 1 && priv.tk.addr) + kill_proc(&priv.tk, pfn, flags); ++ else ++ ret = 0; + mmap_read_unlock(p->mm); +- return ret ? -EFAULT : -EHWPOISON; ++ return ret > 0 ? -EHWPOISON : -EFAULT; + } + + static const char *action_name[] = { diff --git a/queue-5.17/mm-migrate-fix-establishing-demotion-target.patch b/queue-5.17/mm-migrate-fix-establishing-demotion-target.patch new file mode 100644 index 00000000000..b17fa0b26f4 --- /dev/null +++ b/queue-5.17/mm-migrate-fix-establishing-demotion-target.patch @@ -0,0 +1,85 @@ +From fc89213a636c3735eb3386f10a34c082271b4192 Mon Sep 17 00:00:00 2001 +From: Huang Ying +Date: Tue, 22 Mar 2022 14:46:05 -0700 +Subject: mm,migrate: fix establishing demotion target + +From: Huang Ying + +commit fc89213a636c3735eb3386f10a34c082271b4192 upstream. + +In commit ac16ec835314 ("mm: migrate: support multiple target nodes +demotion"), after the first demotion target node is found, we will +continue to check the next candidate obtained via find_next_best_node(). +This is to find all demotion target nodes with same NUMA distance. But +one side effect of find_next_best_node() is that the candidate node +returned will be set in "used" parameter, even if the candidate node isn't +passed in the following NUMA distance checking, the candidate node will +not be used as demotion target node for the following nodes. For example, +for system as follows, + +node distances: +node 0 1 2 3 + 0: 10 21 17 28 + 1: 21 10 28 17 + 2: 17 28 10 28 + 3: 28 17 28 10 + +when we establish demotion target node for node 0, in the first round node +2 is added to the demotion target node set. Then in the second round, +node 3 is checked and failed because distance(0, 3) > distance(0, 2). But +node 3 is set in "used" nodemask too. When we establish demotion target +node for node 1, there is no available node. This is wrong, node 3 should +be set as the demotion target of node 1. + +To fix this, if the candidate node is failed to pass the distance +checking, it will be cleared in "used" nodemask. So that it can be used +for the following node. + +The bug can be reproduced and fixed with this patch on a 2 socket server +machine with DRAM and PMEM. + +Link: https://lkml.kernel.org/r/20220128055940.1792614-1-ying.huang@intel.com +Fixes: ac16ec835314 ("mm: migrate: support multiple target nodes demotion") +Signed-off-by: "Huang, Ying" +Reviewed-by: Baolin Wang +Cc: Baolin Wang +Cc: Dave Hansen +Cc: Zi Yan +Cc: Oscar Salvador +Cc: Yang Shi +Cc: zhongjiang-ali +Cc: Xunlei Pang +Cc: Mel Gorman +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/migrate.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- a/mm/migrate.c ++++ b/mm/migrate.c +@@ -3085,18 +3085,21 @@ static int establish_migrate_target(int + if (best_distance != -1) { + val = node_distance(node, migration_target); + if (val > best_distance) +- return NUMA_NO_NODE; ++ goto out_clear; + } + + index = nd->nr; + if (WARN_ONCE(index >= DEMOTION_TARGET_NODES, + "Exceeds maximum demotion target nodes\n")) +- return NUMA_NO_NODE; ++ goto out_clear; + + nd->nodes[index] = migration_target; + nd->nr++; + + return migration_target; ++out_clear: ++ node_clear(migration_target, *used); ++ return NUMA_NO_NODE; + } + + /* diff --git a/queue-5.17/mm-mlock-fix-potential-imbalanced-rlimit-ucounts-adjustment.patch b/queue-5.17/mm-mlock-fix-potential-imbalanced-rlimit-ucounts-adjustment.patch new file mode 100644 index 00000000000..c64d2e985d0 --- /dev/null +++ b/queue-5.17/mm-mlock-fix-potential-imbalanced-rlimit-ucounts-adjustment.patch @@ -0,0 +1,37 @@ +From 5c2a956c3eea173b2bc89f632507c0eeaebf6c4a Mon Sep 17 00:00:00 2001 +From: Miaohe Lin +Date: Tue, 22 Mar 2022 14:44:56 -0700 +Subject: mm/mlock: fix potential imbalanced rlimit ucounts adjustment + +From: Miaohe Lin + +commit 5c2a956c3eea173b2bc89f632507c0eeaebf6c4a upstream. + +user_shm_lock forgets to set allowed to 0 when get_ucounts fails. So +the later user_shm_unlock might do the extra dec_rlimit_ucounts. Fix +this by resetting allowed to 0. + +Link: https://lkml.kernel.org/r/20220310132417.41189-1-linmiaohe@huawei.com +Fixes: d7c9e99aee48 ("Reimplement RLIMIT_MEMLOCK on top of ucounts") +Signed-off-by: Miaohe Lin +Reviewed-by: Andrew Morton +Acked-by: Hugh Dickins +Cc: Herbert van den Bergh +Cc: Chris Mason +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/mlock.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/mm/mlock.c ++++ b/mm/mlock.c +@@ -838,6 +838,7 @@ int user_shm_lock(size_t size, struct uc + } + if (!get_ucounts(ucounts)) { + dec_rlimit_ucounts(ucounts, UCOUNT_RLIMIT_MEMLOCK, locked); ++ allowed = 0; + goto out; + } + allowed = 1; diff --git a/queue-5.17/mm-shmem-fix-missing-cache-flush-in-shmem_mfill_atomic_pte.patch b/queue-5.17/mm-shmem-fix-missing-cache-flush-in-shmem_mfill_atomic_pte.patch new file mode 100644 index 00000000000..2096e8fe942 --- /dev/null +++ b/queue-5.17/mm-shmem-fix-missing-cache-flush-in-shmem_mfill_atomic_pte.patch @@ -0,0 +1,51 @@ +From 19b482c29b6f3805f1d8e93015847b89e2f7f3b1 Mon Sep 17 00:00:00 2001 +From: Muchun Song +Date: Tue, 22 Mar 2022 14:42:05 -0700 +Subject: mm: shmem: fix missing cache flush in shmem_mfill_atomic_pte() + +From: Muchun Song + +commit 19b482c29b6f3805f1d8e93015847b89e2f7f3b1 upstream. + +userfaultfd calls shmem_mfill_atomic_pte() which does not do any cache +flushing for the target page. Then the target page will be mapped to +the user space with a different address (user address), which might have +an alias issue with the kernel address used to copy the data from the +user to. Insert flush_dcache_page() in non-zero-page case. And replace +clear_highpage() with clear_user_highpage() which already considers the +cache maintenance. + +Link: https://lkml.kernel.org/r/20220210123058.79206-6-songmuchun@bytedance.com +Fixes: 8d1039634206 ("userfaultfd: shmem: add shmem_mfill_zeropage_pte for userfaultfd support") +Fixes: 4c27fe4c4c84 ("userfaultfd: shmem: add shmem_mcopy_atomic_pte for userfaultfd support") +Signed-off-by: Muchun Song +Reviewed-by: Mike Kravetz +Cc: Axel Rasmussen +Cc: David Rientjes +Cc: Fam Zheng +Cc: Kirill A. Shutemov +Cc: Lars Persson +Cc: Peter Xu +Cc: Xiongchun Duan +Cc: Zi Yan +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/shmem.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/mm/shmem.c ++++ b/mm/shmem.c +@@ -2357,8 +2357,10 @@ int shmem_mfill_atomic_pte(struct mm_str + /* don't free the page */ + goto out_unacct_blocks; + } ++ ++ flush_dcache_page(page); + } else { /* ZEROPAGE */ +- clear_highpage(page); ++ clear_user_highpage(page, dst_addr); + } + } else { + page = *pagep; diff --git a/queue-5.17/mm-userfaultfd-fix-missing-cache-flush-in-mcopy_atomic_pte-and-__mcopy_atomic.patch b/queue-5.17/mm-userfaultfd-fix-missing-cache-flush-in-mcopy_atomic_pte-and-__mcopy_atomic.patch new file mode 100644 index 00000000000..4dd88dc1dd7 --- /dev/null +++ b/queue-5.17/mm-userfaultfd-fix-missing-cache-flush-in-mcopy_atomic_pte-and-__mcopy_atomic.patch @@ -0,0 +1,55 @@ +From 7c25a0b89a487878b0691e6524fb5a8827322194 Mon Sep 17 00:00:00 2001 +From: Muchun Song +Date: Tue, 22 Mar 2022 14:42:08 -0700 +Subject: mm: userfaultfd: fix missing cache flush in mcopy_atomic_pte() and __mcopy_atomic() + +From: Muchun Song + +commit 7c25a0b89a487878b0691e6524fb5a8827322194 upstream. + +userfaultfd calls mcopy_atomic_pte() and __mcopy_atomic() which do not +do any cache flushing for the target page. Then the target page will be +mapped to the user space with a different address (user address), which +might have an alias issue with the kernel address used to copy the data +from the user to. Fix this by insert flush_dcache_page() after +copy_from_user() succeeds. + +Link: https://lkml.kernel.org/r/20220210123058.79206-7-songmuchun@bytedance.com +Fixes: b6ebaedb4cb1 ("userfaultfd: avoid mmap_sem read recursion in mcopy_atomic") +Fixes: c1a4de99fada ("userfaultfd: mcopy_atomic|mfill_zeropage: UFFDIO_COPY|UFFDIO_ZEROPAGE preparation") +Signed-off-by: Muchun Song +Cc: Axel Rasmussen +Cc: David Rientjes +Cc: Fam Zheng +Cc: Kirill A. Shutemov +Cc: Lars Persson +Cc: Mike Kravetz +Cc: Peter Xu +Cc: Xiongchun Duan +Cc: Zi Yan +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/userfaultfd.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/mm/userfaultfd.c ++++ b/mm/userfaultfd.c +@@ -153,6 +153,8 @@ static int mcopy_atomic_pte(struct mm_st + /* don't free the page */ + goto out; + } ++ ++ flush_dcache_page(page); + } else { + page = *pagep; + *pagep = NULL; +@@ -628,6 +630,7 @@ retry: + err = -EFAULT; + goto out; + } ++ flush_dcache_page(page); + goto retry; + } else + BUG_ON(page); diff --git a/queue-5.17/series b/queue-5.17/series index d59a7a093e6..12340dfef46 100644 --- a/queue-5.17/series +++ b/queue-5.17/series @@ -1,3 +1,11 @@ bluetooth-fix-the-creation-of-hdev-name.patch rfkill-uapi-fix-rfkill_ioctl_max_size-ioctl-request-definition.patch udf-avoid-using-stale-lengthofimpuse.patch +mm-fix-missing-cache-flush-for-all-tail-pages-of-compound-page.patch +mm-hugetlb-fix-missing-cache-flush-in-copy_huge_page_from_user.patch +mm-hugetlb-fix-missing-cache-flush-in-hugetlb_mcopy_atomic_pte.patch +mm-shmem-fix-missing-cache-flush-in-shmem_mfill_atomic_pte.patch +mm-userfaultfd-fix-missing-cache-flush-in-mcopy_atomic_pte-and-__mcopy_atomic.patch +mm-hwpoison-fix-error-page-recovered-but-reported-not-recovered.patch +mm-mlock-fix-potential-imbalanced-rlimit-ucounts-adjustment.patch +mm-migrate-fix-establishing-demotion-target.patch