May 2024 - Linux-stable-mirror

[merged mm-hotfixes-stable] fs-proc-task_mmu-fix-uffd-wp-confusion-in-pagemap_scan_pmd_entry.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: fs/proc/task_mmu: fix uffd-wp confusion in pagemap_scan_pmd_entry() has been removed from the -mm tree. Its filename was fs-proc-task_mmu-fix-uffd-wp-confusion-in-pagemap_scan_pmd_entry.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Ryan Roberts <ryan.roberts(a)arm.com> Subject: fs/proc/task_mmu: fix uffd-wp confusion in pagemap_scan_pmd_entry() Date: Mon, 29 Apr 2024 12:41:04 +0100 pagemap_scan_pmd_entry() checks if uffd-wp is set on each pte to avoid unnecessary if set. However it was previously checking with `pte_uffd_wp(ptep_get(pte))` without first confirming that the pte was present. It is only valid to call pte_uffd_wp() for present ptes. For swap ptes, pte_swp_uffd_wp() must be called because the uffd-wp bit may be kept in a different position, depending on the arch. This was leading to test failures in the pagemap_ioctl mm selftest, when bringing up uffd-wp support on arm64 due to incorrectly interpretting the uffd-wp status of migration entries. Let's fix this by using the correct check based on pte_present(). While we are at it, let's pass the pte to make_uffd_wp_pte() to avoid the pointless extra ptep_get() which can't be optimized out due to READ_ONCE() on many arches. Link: https://lkml.kernel.org/r/20240429114104.182890-1-ryan.roberts@arm.com Fixes: 12f6b01a0bcb ("fs/proc/task_mmu: add fast paths to get/clear PAGE_IS_WRITTEN flag") Closes: https://lore.kernel.org/linux-arm-kernel/ZiuyGXt0XWwRgFh9@x1n/ Signed-off-by: Ryan Roberts <ryan.roberts(a)arm.com> Acked-by: David Hildenbrand <david(a)redhat.com> Reviewed-by: Muhammad Usama Anjum <usama.anjum(a)collabora.com> Tested-by: Muhammad Usama Anjum <usama.anjum(a)collabora.com> Cc: Peter Xu <peterx(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/proc/task_mmu.c | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) --- a/fs/proc/task_mmu.c~fs-proc-task_mmu-fix-uffd-wp-confusion-in-pagemap_scan_pmd_entry +++ a/fs/proc/task_mmu.c @@ -1817,10 +1817,8 @@ static unsigned long pagemap_page_catego } static void make_uffd_wp_pte(struct vm_area_struct *vma, - unsigned long addr, pte_t *pte) + unsigned long addr, pte_t *pte, pte_t ptent) { - pte_t ptent = ptep_get(pte); - if (pte_present(ptent)) { pte_t old_pte; @@ -2175,9 +2173,12 @@ static int pagemap_scan_pmd_entry(pmd_t if ((p->arg.flags & PM_SCAN_WP_MATCHING) && !p->vec_out) { /* Fast path for performing exclusive WP */ for (addr = start; addr != end; pte++, addr += PAGE_SIZE) { - if (pte_uffd_wp(ptep_get(pte))) + pte_t ptent = ptep_get(pte); + + if ((pte_present(ptent) && pte_uffd_wp(ptent)) || + pte_swp_uffd_wp_any(ptent)) continue; - make_uffd_wp_pte(vma, addr, pte); + make_uffd_wp_pte(vma, addr, pte, ptent); if (!flush_end) start = addr; flush_end = addr + PAGE_SIZE; @@ -2190,8 +2191,10 @@ static int pagemap_scan_pmd_entry(pmd_t p->arg.return_mask == PAGE_IS_WRITTEN) { for (addr = start; addr < end; pte++, addr += PAGE_SIZE) { unsigned long next = addr + PAGE_SIZE; + pte_t ptent = ptep_get(pte); - if (pte_uffd_wp(ptep_get(pte))) + if ((pte_present(ptent) && pte_uffd_wp(ptent)) || + pte_swp_uffd_wp_any(ptent)) continue; ret = pagemap_scan_output(p->cur_vma_category | PAGE_IS_WRITTEN, p, addr, &next); @@ -2199,7 +2202,7 @@ static int pagemap_scan_pmd_entry(pmd_t break; if (~p->arg.flags & PM_SCAN_WP_MATCHING) continue; - make_uffd_wp_pte(vma, addr, pte); + make_uffd_wp_pte(vma, addr, pte, ptent); if (!flush_end) start = addr; flush_end = next; @@ -2208,8 +2211,9 @@ static int pagemap_scan_pmd_entry(pmd_t } for (addr = start; addr != end; pte++, addr += PAGE_SIZE) { + pte_t ptent = ptep_get(pte); unsigned long categories = p->cur_vma_category | - pagemap_page_category(p, vma, addr, ptep_get(pte)); + pagemap_page_category(p, vma, addr, ptent); unsigned long next = addr + PAGE_SIZE; if (!pagemap_scan_is_interesting_page(categories, p)) @@ -2224,7 +2228,7 @@ static int pagemap_scan_pmd_entry(pmd_t if (~categories & PAGE_IS_WRITTEN) continue; - make_uffd_wp_pte(vma, addr, pte); + make_uffd_wp_pte(vma, addr, pte, ptent); if (!flush_end) start = addr; flush_end = next; _ Patches currently in -mm which might be from ryan.roberts(a)arm.com are selftests-mm-soft-dirty-should-fail-if-a-testcase-fails.patch mm-debug_vm_pgtable-test-pmd_leaf-behavior-with-pmd_mkinvalid.patch mm-fix-race-between-__split_huge_pmd_locked-and-gup-fast.patch

11 months, 3 weeks

1
0
0 0

[merged mm-hotfixes-stable] fs-proc-task_mmu-fix-loss-of-young-dirty-bits-during-pagemap-scan.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: fs/proc/task_mmu: fix loss of young/dirty bits during pagemap scan has been removed from the -mm tree. Its filename was fs-proc-task_mmu-fix-loss-of-young-dirty-bits-during-pagemap-scan.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Ryan Roberts <ryan.roberts(a)arm.com> Subject: fs/proc/task_mmu: fix loss of young/dirty bits during pagemap scan Date: Mon, 29 Apr 2024 12:40:17 +0100 make_uffd_wp_pte() was previously doing: pte = ptep_get(ptep); ptep_modify_prot_start(ptep); pte = pte_mkuffd_wp(pte); ptep_modify_prot_commit(ptep, pte); But if another thread accessed or dirtied the pte between the first 2 calls, this could lead to loss of that information. Since ptep_modify_prot_start() gets and clears atomically, the following is the correct pattern and prevents any possible race. Any access after the first call would see an invalid pte and cause a fault: pte = ptep_modify_prot_start(ptep); pte = pte_mkuffd_wp(pte); ptep_modify_prot_commit(ptep, pte); Link: https://lkml.kernel.org/r/20240429114017.182570-1-ryan.roberts@arm.com Fixes: 52526ca7fdb9 ("fs/proc/task_mmu: implement IOCTL to get and optionally clear info about PTEs") Signed-off-by: Ryan Roberts <ryan.roberts(a)arm.com> Acked-by: David Hildenbrand <david(a)redhat.com> Cc: Muhammad Usama Anjum <usama.anjum(a)collabora.com> Cc: Peter Xu <peterx(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/proc/task_mmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/proc/task_mmu.c~fs-proc-task_mmu-fix-loss-of-young-dirty-bits-during-pagemap-scan +++ a/fs/proc/task_mmu.c @@ -1825,7 +1825,7 @@ static void make_uffd_wp_pte(struct vm_a pte_t old_pte; old_pte = ptep_modify_prot_start(vma, addr, pte); - ptent = pte_mkuffd_wp(ptent); + ptent = pte_mkuffd_wp(old_pte); ptep_modify_prot_commit(vma, addr, pte, old_pte, ptent); } else if (is_swap_pte(ptent)) { ptent = pte_swp_mkuffd_wp(ptent); _ Patches currently in -mm which might be from ryan.roberts(a)arm.com are selftests-mm-soft-dirty-should-fail-if-a-testcase-fails.patch mm-debug_vm_pgtable-test-pmd_leaf-behavior-with-pmd_mkinvalid.patch mm-fix-race-between-__split_huge_pmd_locked-and-gup-fast.patch

11 months, 3 weeks

1
0
0 0

[merged mm-hotfixes-stable] mm-use-memalloc_nofs_save-in-page_cache_ra_order.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm: use memalloc_nofs_save() in page_cache_ra_order() has been removed from the -mm tree. Its filename was mm-use-memalloc_nofs_save-in-page_cache_ra_order.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Kefeng Wang <wangkefeng.wang(a)huawei.com> Subject: mm: use memalloc_nofs_save() in page_cache_ra_order() Date: Fri, 26 Apr 2024 19:29:38 +0800 See commit f2c817bed58d ("mm: use memalloc_nofs_save in readahead path"), ensure that page_cache_ra_order() do not attempt to reclaim file-backed pages too, or it leads to a deadlock, found issue when test ext4 large folio. INFO: task DataXceiver for:7494 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:DataXceiver for state:D stack:0 pid:7494 ppid:1 flags:0x00000200 Call trace: __switch_to+0x14c/0x240 __schedule+0x82c/0xdd0 schedule+0x58/0xf0 io_schedule+0x24/0xa0 __folio_lock+0x130/0x300 migrate_pages_batch+0x378/0x918 migrate_pages+0x350/0x700 compact_zone+0x63c/0xb38 compact_zone_order+0xc0/0x118 try_to_compact_pages+0xb0/0x280 __alloc_pages_direct_compact+0x98/0x248 __alloc_pages+0x510/0x1110 alloc_pages+0x9c/0x130 folio_alloc+0x20/0x78 filemap_alloc_folio+0x8c/0x1b0 page_cache_ra_order+0x174/0x308 ondemand_readahead+0x1c8/0x2b8 page_cache_async_ra+0x68/0xb8 filemap_readahead.isra.0+0x64/0xa8 filemap_get_pages+0x3fc/0x5b0 filemap_splice_read+0xf4/0x280 ext4_file_splice_read+0x2c/0x48 [ext4] vfs_splice_read.part.0+0xa8/0x118 splice_direct_to_actor+0xbc/0x288 do_splice_direct+0x9c/0x108 do_sendfile+0x328/0x468 __arm64_sys_sendfile64+0x8c/0x148 invoke_syscall+0x4c/0x118 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x4c/0x1f8 el0t_64_sync_handler+0xc0/0xc8 el0t_64_sync+0x188/0x190 Link: https://lkml.kernel.org/r/20240426112938.124740-1-wangkefeng.wang@huawei.com Fixes: 793917d997df ("mm/readahead: Add large folio readahead") Signed-off-by: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Zhang Yi <yi.zhang(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/readahead.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/mm/readahead.c~mm-use-memalloc_nofs_save-in-page_cache_ra_order +++ a/mm/readahead.c @@ -490,6 +490,7 @@ void page_cache_ra_order(struct readahea pgoff_t index = readahead_index(ractl); pgoff_t limit = (i_size_read(mapping->host) - 1) >> PAGE_SHIFT; pgoff_t mark = index + ra->size - ra->async_size; + unsigned int nofs; int err = 0; gfp_t gfp = readahead_gfp_mask(mapping); @@ -504,6 +505,8 @@ void page_cache_ra_order(struct readahea new_order = min_t(unsigned int, new_order, ilog2(ra->size)); } + /* See comment in page_cache_ra_unbounded() */ + nofs = memalloc_nofs_save(); filemap_invalidate_lock_shared(mapping); while (index <= limit) { unsigned int order = new_order; @@ -527,6 +530,7 @@ void page_cache_ra_order(struct readahea read_pages(ractl); filemap_invalidate_unlock_shared(mapping); + memalloc_nofs_restore(nofs); /* * If there were already pages in the page cache, then we may have _ Patches currently in -mm which might be from wangkefeng.wang(a)huawei.com are arm64-mm-drop-vm_fault_badmap-vm_fault_badaccess.patch arm-mm-drop-vm_fault_badmap-vm_fault_badaccess.patch mm-move-mm-counter-updating-out-of-set_pte_range.patch mm-filemap-batch-mm-counter-updating-in-filemap_map_pages.patch mm-swapfile-check-usable-swap-device-in-__folio_throttle_swaprate.patch mm-memory-check-userfaultfd_wp-in-vmf_orig_pte_uffd_wp.patch

11 months, 3 weeks

1
0
0 0

[merged mm-hotfixes-stable] kmsan-compiler_types-declare-__no_sanitize_or_inline.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: kmsan: compiler_types: declare __no_sanitize_or_inline has been removed from the -mm tree. Its filename was kmsan-compiler_types-declare-__no_sanitize_or_inline.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Alexander Potapenko <glider(a)google.com> Subject: kmsan: compiler_types: declare __no_sanitize_or_inline Date: Fri, 26 Apr 2024 11:16:22 +0200 It turned out that KMSAN instruments READ_ONCE_NOCHECK(), resulting in false positive reports, because __no_sanitize_or_inline enforced inlining. Properly declare __no_sanitize_or_inline under __SANITIZE_MEMORY__, so that it does not __always_inline the annotated function. Link: https://lkml.kernel.org/r/20240426091622.3846771-1-glider@google.com Fixes: 5de0ce85f5a4 ("kmsan: mark noinstr as __no_sanitize_memory") Signed-off-by: Alexander Potapenko <glider(a)google.com> Reported-by: syzbot+355c5bb8c1445c871ee8(a)syzkaller.appspotmail.com Link: https://lkml.kernel.org/r/000000000000826ac1061675b0e3@google.com Cc: <stable(a)vger.kernel.org> Reviewed-by: Marco Elver <elver(a)google.com> Cc: Dmitry Vyukov <dvyukov(a)google.com> Cc: Miguel Ojeda <ojeda(a)kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/compiler_types.h | 11 +++++++++++ 1 file changed, 11 insertions(+) --- a/include/linux/compiler_types.h~kmsan-compiler_types-declare-__no_sanitize_or_inline +++ a/include/linux/compiler_types.h @@ -278,6 +278,17 @@ struct ftrace_likely_data { # define __no_kcsan #endif +#ifdef __SANITIZE_MEMORY__ +/* + * Similarly to KASAN and KCSAN, KMSAN loses function attributes of inlined + * functions, therefore disabling KMSAN checks also requires disabling inlining. + * + * __no_sanitize_or_inline effectively prevents KMSAN from reporting errors + * within the function and marks all its outputs as initialized. + */ +# define __no_sanitize_or_inline __no_kmsan_checks notrace __maybe_unused +#endif + #ifndef __no_sanitize_or_inline #define __no_sanitize_or_inline __always_inline #endif _ Patches currently in -mm which might be from glider(a)google.com are

11 months, 3 weeks

1
0
0 0

[merged mm-hotfixes-stable] maple_tree-fix-mas_empty_area_rev-null-pointer-dereference.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: maple_tree: fix mas_empty_area_rev() null pointer dereference has been removed from the -mm tree. Its filename was maple_tree-fix-mas_empty_area_rev-null-pointer-dereference.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: "Liam R. Howlett" <Liam.Howlett(a)oracle.com> Subject: maple_tree: fix mas_empty_area_rev() null pointer dereference Date: Mon, 22 Apr 2024 16:33:49 -0400 Currently the code calls mas_start() followed by mas_data_end() if the maple state is MA_START, but mas_start() may return with the maple state node == NULL. This will lead to a null pointer dereference when checking information in the NULL node, which is done in mas_data_end(). Avoid setting the offset if there is no node by waiting until after the maple state is checked for an empty or single entry state. A user could trigger the events to cause a kernel oops by unmapping all vmas to produce an empty maple tree, then mapping a vma that would cause the scenario described above. Link: https://lkml.kernel.org/r/20240422203349.2418465-1-Liam.Howlett@oracle.com Fixes: 54a611b60590 ("Maple Tree: add new data structure") Signed-off-by: Liam R. Howlett <Liam.Howlett(a)oracle.com> Reported-by: Marius Fleischer <fleischermarius(a)gmail.com> Closes: https://lore.kernel.org/lkml/CAJg=8jyuSxDL6XvqEXY_66M20psRK2J53oBTP+fjV5xpW… Link: https://lore.kernel.org/lkml/CAJg=8jyuSxDL6XvqEXY_66M20psRK2J53oBTP+fjV5xpW… Tested-by: Marius Fleischer <fleischermarius(a)gmail.com> Tested-by: Sidhartha Kumar <sidhartha.kumar(a)oracle.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/maple_tree.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) --- a/lib/maple_tree.c~maple_tree-fix-mas_empty_area_rev-null-pointer-dereference +++ a/lib/maple_tree.c @@ -5109,18 +5109,18 @@ int mas_empty_area_rev(struct ma_state * if (size == 0 || max - min < size - 1) return -EINVAL; - if (mas_is_start(mas)) { + if (mas_is_start(mas)) mas_start(mas); - mas->offset = mas_data_end(mas); - } else if (mas->offset >= 2) { - mas->offset -= 2; - } else if (!mas_rewind_node(mas)) { + else if ((mas->offset < 2) && (!mas_rewind_node(mas))) return -EBUSY; - } - /* Empty set. */ - if (mas_is_none(mas) || mas_is_ptr(mas)) + if (unlikely(mas_is_none(mas) || mas_is_ptr(mas))) return mas_sparse_area(mas, min, max, size, false); + else if (mas->offset >= 2) + mas->offset -= 2; + else + mas->offset = mas_data_end(mas); + /* The start of the window can only be within these values. */ mas->index = min; _ Patches currently in -mm which might be from Liam.Howlett(a)oracle.com are

11 months, 3 weeks

1
0
0 0

[merged mm-hotfixes-stable] mm-userfaultfd-reset-ptes-when-close-for-wr-protected-ones.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/userfaultfd: reset ptes when close() for wr-protected ones has been removed from the -mm tree. Its filename was mm-userfaultfd-reset-ptes-when-close-for-wr-protected-ones.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Peter Xu <peterx(a)redhat.com> Subject: mm/userfaultfd: reset ptes when close() for wr-protected ones Date: Mon, 22 Apr 2024 09:33:11 -0400 Userfaultfd unregister includes a step to remove wr-protect bits from all the relevant pgtable entries, but that only covered an explicit UFFDIO_UNREGISTER ioctl, not a close() on the userfaultfd itself. Cover that too. This fixes a WARN trace. The only user visible side effect is the user can observe leftover wr-protect bits even if the user close()ed on an userfaultfd when releasing the last reference of it. However hopefully that should be harmless, and nothing bad should happen even if so. This change is now more important after the recent page-table-check patch we merged in mm-unstable (446dd9ad37d0 ("mm/page_table_check: support userfault wr-protect entries")), as we'll do sanity check on uffd-wp bits without vma context. So it's better if we can 100% guarantee no uffd-wp bit leftovers, to make sure each report will be valid. Link: https://lore.kernel.org/all/000000000000ca4df20616a0fe16@google.com/ Fixes: f369b07c8614 ("mm/uffd: reset write protection when unregister with wp-mode") Analyzed-by: David Hildenbrand <david(a)redhat.com> Link: https://lkml.kernel.org/r/20240422133311.2987675-1-peterx@redhat.com Reported-by: syzbot+d8426b591c36b21c750e(a)syzkaller.appspotmail.com Signed-off-by: Peter Xu <peterx(a)redhat.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Cc: Nadav Amit <nadav.amit(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/userfaultfd.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/fs/userfaultfd.c~mm-userfaultfd-reset-ptes-when-close-for-wr-protected-ones +++ a/fs/userfaultfd.c @@ -895,6 +895,10 @@ static int userfaultfd_release(struct in prev = vma; continue; } + /* Reset ptes for the whole vma range if wr-protected */ + if (userfaultfd_wp(vma)) + uffd_wp_range(vma, vma->vm_start, + vma->vm_end - vma->vm_start, false); new_flags = vma->vm_flags & ~__VM_UFFD_FLAGS; vma = vma_modify_flags_uffd(&vmi, prev, vma, vma->vm_start, vma->vm_end, new_flags, _ Patches currently in -mm which might be from peterx(a)redhat.com are mm-hugetlb-assert-hugetlb_lock-in-__hugetlb_cgroup_commit_charge.patch mm-page_table_check-support-userfault-wr-protect-entries.patch mm-gup-fix-hugepd-handling-in-hugetlb-rework.patch

11 months, 3 weeks

1
0
0 0

+ docs-admin-guide-mm-damon-usage-fix-wrong-schemes-effective-quota-update-command.patch added to mm-unstable branch

by Andrew Morton

The patch titled Subject: Docs/admin-guide/mm/damon/usage: fix wrong schemes effective quota update command has been added to the -mm mm-unstable branch. Its filename is docs-admin-guide-mm-damon-usage-fix-wrong-schemes-effective-quota-update-command.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: SeongJae Park <sj(a)kernel.org> Subject: Docs/admin-guide/mm/damon/usage: fix wrong schemes effective quota update command Date: Fri, 3 May 2024 11:03:15 -0700 To update effective size quota of DAMOS schemes on DAMON sysfs file interface, user should write 'update_schemes_effective_quotas' to the kdamond 'state' file. But the document is mistakenly saying the input string as 'update_schemes_effective_bytes'. Fix it (s/bytes/quotas/). Link: https://lkml.kernel.org/r/20240503180318.72798-8-sj@kernel.org Fixes: a6068d6dfa2f ("Docs/admin-guide/mm/damon/usage: document effective_bytes file") Signed-off-by: SeongJae Park <sj(a)kernel.org> Cc: <stable(a)vger.kernel.org> [6.9.x] Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Shuah Khan <shuah(a)kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- Documentation/admin-guide/mm/damon/usage.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/Documentation/admin-guide/mm/damon/usage.rst~docs-admin-guide-mm-damon-usage-fix-wrong-schemes-effective-quota-update-command +++ a/Documentation/admin-guide/mm/damon/usage.rst @@ -153,7 +153,7 @@ Users can write below commands for the k - ``clear_schemes_tried_regions``: Clear the DAMON-based operating scheme action tried regions directory for each DAMON-based operation scheme of the kdamond. -- ``update_schemes_effective_bytes``: Update the contents of +- ``update_schemes_effective_quotas``: Update the contents of ``effective_bytes`` files for each DAMON-based operation scheme of the kdamond. For more details, refer to :ref:`quotas directory <sysfs_quotas>`. @@ -342,7 +342,7 @@ Based on the user-specified :ref:`goal < effective size quota is further adjusted. Reading ``effective_bytes`` returns the current effective size quota. The file is not updated in real time, so users should ask DAMON sysfs interface to update the content of the file for -the stats by writing a special keyword, ``update_schemes_effective_bytes`` to +the stats by writing a special keyword, ``update_schemes_effective_quotas`` to the relevant ``kdamonds/<N>/state`` file. Under ``weights`` directory, three files (``sz_permil``, _ Patches currently in -mm which might be from sj(a)kernel.org are mm-damon-paddr-implement-damon_folio_young.patch mm-damon-paddr-implement-damon_folio_mkold.patch mm-damon-add-damos-filter-type-young.patch mm-damon-paddr-implement-damos-filter-type-young.patch docs-mm-damon-design-document-young-page-type-damos-filter.patch docs-admin-guide-mm-damon-usage-update-for-young-page-type-damos-filter.patch docs-abi-damon-update-for-youg-page-type-damos-filter.patch mm-damon-paddr-avoid-unnecessary-page-level-access-check-for-pageout-damos-action.patch mm-damon-paddr-do-page-level-access-check-for-pageout-damos-action-on-its-own.patch mm-vmscan-remove-ignore_references-argument-of-reclaim_pages.patch mm-vmscan-remove-ignore_references-argument-of-reclaim_folio_list.patch selftests-damon-_damon_sysfs-support-quota-goals.patch selftests-damon-add-a-test-for-damos-quota-goal.patch mm-damon-core-initialize-esz_bp-from-damos_quota_init_priv.patch selftests-damon-_damon_sysfs-check-errors-from-nr_schemes-file-reads.patch selftests-damon-_damon_sysfs-find-sysfs-mount-point-from-proc-mounts.patch selftests-damon-_damon_sysfs-use-is-instead-of-==-for-none.patch selftests-damon-classify-tests-for-functionalities-and-regressions.patch docs-admin-guide-mm-damon-usage-fix-wrong-example-of-damos-filter-matching-sysfs-file.patch docs-admin-guide-mm-damon-usage-fix-wrong-schemes-effective-quota-update-command.patch docs-mm-damon-design-use-a-list-for-supported-filters.patch docs-mm-damon-maintainer-profile-change-the-maintainers-timezone-from-pst-to-pt.patch docs-mm-damon-maintainer-profile-allow-posting-patches-based-on-damon-next-tree.patch

11 months, 3 weeks

1
0
0 0

+ docs-admin-guide-mm-damon-usage-fix-wrong-example-of-damos-filter-matching-sysfs-file.patch added to mm-unstable branch

by Andrew Morton

The patch titled Subject: Docs/admin-guide/mm/damon/usage: fix wrong example of DAMOS filter matching sysfs file has been added to the -mm mm-unstable branch. Its filename is docs-admin-guide-mm-damon-usage-fix-wrong-example-of-damos-filter-matching-sysfs-file.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: SeongJae Park <sj(a)kernel.org> Subject: Docs/admin-guide/mm/damon/usage: fix wrong example of DAMOS filter matching sysfs file Date: Fri, 3 May 2024 11:03:14 -0700 The example usage of DAMOS filter sysfs files, specifically the part of 'matching' file writing for memcg type filter, is wrong. The intention is to exclude pages of a memcg that already getting enough care from a given scheme, but the example is setting the filter to apply the scheme to only the pages of the memcg. Fix it. Link: https://lkml.kernel.org/r/20240503180318.72798-7-sj@kernel.org Fixes: 9b7f9322a530 ("Docs/admin-guide/mm/damon/usage: document DAMOS filters of sysfs") Closes: https://lore.kernel.org/r/20240317191358.97578-1-sj@kernel.org Signed-off-by: SeongJae Park <sj(a)kernel.org> Cc: <stable(a)vger.kernel.org> [6.3.x] Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Shuah Khan <shuah(a)kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- Documentation/admin-guide/mm/damon/usage.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/Documentation/admin-guide/mm/damon/usage.rst~docs-admin-guide-mm-damon-usage-fix-wrong-example-of-damos-filter-matching-sysfs-file +++ a/Documentation/admin-guide/mm/damon/usage.rst @@ -434,7 +434,7 @@ pages of all memory cgroups except ``/ha # # further filter out all cgroups except one at '/having_care_already' echo memcg > 1/type echo /having_care_already > 1/memcg_path - echo N > 1/matching + echo Y > 1/matching Note that ``anon`` and ``memcg`` filters are currently supported only when ``paddr`` :ref:`implementation <sysfs_context>` is being used. _ Patches currently in -mm which might be from sj(a)kernel.org are mm-damon-paddr-implement-damon_folio_young.patch mm-damon-paddr-implement-damon_folio_mkold.patch mm-damon-add-damos-filter-type-young.patch mm-damon-paddr-implement-damos-filter-type-young.patch docs-mm-damon-design-document-young-page-type-damos-filter.patch docs-admin-guide-mm-damon-usage-update-for-young-page-type-damos-filter.patch docs-abi-damon-update-for-youg-page-type-damos-filter.patch mm-damon-paddr-avoid-unnecessary-page-level-access-check-for-pageout-damos-action.patch mm-damon-paddr-do-page-level-access-check-for-pageout-damos-action-on-its-own.patch mm-vmscan-remove-ignore_references-argument-of-reclaim_pages.patch mm-vmscan-remove-ignore_references-argument-of-reclaim_folio_list.patch selftests-damon-_damon_sysfs-support-quota-goals.patch selftests-damon-add-a-test-for-damos-quota-goal.patch mm-damon-core-initialize-esz_bp-from-damos_quota_init_priv.patch selftests-damon-_damon_sysfs-check-errors-from-nr_schemes-file-reads.patch selftests-damon-_damon_sysfs-find-sysfs-mount-point-from-proc-mounts.patch selftests-damon-_damon_sysfs-use-is-instead-of-==-for-none.patch selftests-damon-classify-tests-for-functionalities-and-regressions.patch docs-admin-guide-mm-damon-usage-fix-wrong-example-of-damos-filter-matching-sysfs-file.patch docs-admin-guide-mm-damon-usage-fix-wrong-schemes-effective-quota-update-command.patch docs-mm-damon-design-use-a-list-for-supported-filters.patch docs-mm-damon-maintainer-profile-change-the-maintainers-timezone-from-pst-to-pt.patch docs-mm-damon-maintainer-profile-allow-posting-patches-based-on-damon-next-tree.patch

11 months, 3 weeks

1
0
0 0

Re: [REGRESSION] Thunderbolt Host Reset Change Causes eGPU Disconnection from 6.8.7=>6.8.8

by Linux regression tracking (Thorsten Leemhuis)

[CCing Mario, who asked for the two suspected commits to be backported] On 05.05.24 03:12, Micha Albert wrote: > > I have an AMD Radeon 6600 XT GPU in a cheap Thunderbolt eGPU board. > In 6.8.7, this works as expected, and my Plymouth screen (including the > LUKS password prompt) shows on my 2 monitors connected to the GPU as > well as my main laptop screen. Upon entering the password, I'm put into > userspace as expected. However, upon upgrading to 6.8.8, I will be > greeted with the regular password prompt, but after entering my password > and waiting for it to be accepted, my eGPU will reset and not function. > I can tell that it resets since I can hear the click of my ATX power > supply turning off and on again, and the status LED of the eGPU board > goes from green to blue and back to green, all in less than a second. > > I talked to a friend, and we found out that the kernel parameter > thunderbolt.host_reset=false fixes the issue. He also thinks that > commits cc4c94 (59a54c upstream) and 11371c (ec8162 upstream) look > suspicious. I've attached the output of dmesg when the error was > occurring, since I'm still able to use my laptop normally when this > happens, just not with my eGPU and its connected displays. Thx for the report. Could you please test if 6.9-rc6 (or a later snapshot; or -rc7, which should be out in about ~18 hours) is affected as well? That would be really important to know. It would also be great if you could try reverting the two patches you mentioned and see if they are really what's causing this. There iirc are two more; maybe you might need to revert some or all of them in the order they were applied. Ciao, Thorsten P.s.: To be sure the issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression tracking bot: #regzbot ^introduced v6.8.7..v6.8.8 #regzbot title thunderbolt: eGPU disconnected during boot

11 months, 4 weeks

3
2
0 0

FAILED: patch "[PATCH] mm/hugetlb: fix DEBUG_LOCKS_WARN_ON(1) when" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x 52ccdde16b6540abe43b6f8d8e1e1ec90b0983af # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024042914-rectified-grab-1bbb@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: 52ccdde16b65 ("mm/hugetlb: fix DEBUG_LOCKS_WARN_ON(1) when dissolve_free_hugetlb_folio()") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 52ccdde16b6540abe43b6f8d8e1e1ec90b0983af Mon Sep 17 00:00:00 2001 From: Miaohe Lin <linmiaohe(a)huawei.com> Date: Fri, 19 Apr 2024 16:58:19 +0800 Subject: [PATCH] mm/hugetlb: fix DEBUG_LOCKS_WARN_ON(1) when dissolve_free_hugetlb_folio() When I did memory failure tests recently, below warning occurs: DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 8 PID: 1011 at kernel/locking/lockdep.c:232 __lock_acquire+0xccb/0x1ca0 Modules linked in: mce_inject hwpoison_inject CPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__lock_acquire+0xccb/0x1ca0 RSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082 RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0 RBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb R10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10 R13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004 FS: 00007ff9f32aa740(0000) GS:ffffa1ce5fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff9f3134ba0 CR3: 00000008484e4000 CR4: 00000000000006f0 Call Trace: <TASK> lock_acquire+0xbe/0x2d0 _raw_spin_lock_irqsave+0x3a/0x60 hugepage_subpool_put_pages.part.0+0xe/0xc0 free_huge_folio+0x253/0x3f0 dissolve_free_huge_page+0x147/0x210 __page_handle_poison+0x9/0x70 memory_failure+0x4e6/0x8c0 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xbc/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff9f3114887 RSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887 RDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001 RBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c R13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00 </TASK> Kernel panic - not syncing: kernel: panic_on_warn set ... CPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> panic+0x326/0x350 check_panic_on_warn+0x4f/0x50 __warn+0x98/0x190 report_bug+0x18e/0x1a0 handle_bug+0x3d/0x70 exc_invalid_op+0x18/0x70 asm_exc_invalid_op+0x1a/0x20 RIP: 0010:__lock_acquire+0xccb/0x1ca0 RSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082 RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0 RBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb R10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10 R13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004 lock_acquire+0xbe/0x2d0 _raw_spin_lock_irqsave+0x3a/0x60 hugepage_subpool_put_pages.part.0+0xe/0xc0 free_huge_folio+0x253/0x3f0 dissolve_free_huge_page+0x147/0x210 __page_handle_poison+0x9/0x70 memory_failure+0x4e6/0x8c0 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xbc/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff9f3114887 RSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887 RDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001 RBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c R13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00 </TASK> After git bisecting and digging into the code, I believe the root cause is that _deferred_list field of folio is unioned with _hugetlb_subpool field. In __update_and_free_hugetlb_folio(), folio->_deferred_list is initialized leading to corrupted folio->_hugetlb_subpool when folio is hugetlb. Later free_huge_folio() will use _hugetlb_subpool and above warning happens. But it is assumed hugetlb flag must have been cleared when calling folio_put() in update_and_free_hugetlb_folio(). This assumption is broken due to below race: CPU1 CPU2 dissolve_free_huge_page update_and_free_pages_bulk update_and_free_hugetlb_folio hugetlb_vmemmap_restore_folios folio_clear_hugetlb_vmemmap_optimized clear_flag = folio_test_hugetlb_vmemmap_optimized if (clear_flag) <-- False, it's already cleared. __folio_clear_hugetlb(folio) <-- Hugetlb is not cleared. folio_put free_huge_folio <-- free_the_page is expected. list_for_each_entry() __folio_clear_hugetlb <-- Too late. Fix this issue by checking whether folio is hugetlb directly instead of checking clear_flag to close the race window. Link: https://lkml.kernel.org/r/20240419085819.1901645-1-linmiaohe@huawei.com Fixes: 32c877191e02 ("hugetlb: do not clear hugetlb dtor until allocating vmemmap") Signed-off-by: Miaohe Lin <linmiaohe(a)huawei.com> Reviewed-by: Oscar Salvador <osalvador(a)suse.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 05371bf54f96..ce7be5c24442 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -1781,7 +1781,7 @@ static void __update_and_free_hugetlb_folio(struct hstate *h, * If vmemmap pages were allocated above, then we need to clear the * hugetlb destructor under the hugetlb lock. */ - if (clear_dtor) { + if (folio_test_hugetlb(folio)) { spin_lock_irq(&hugetlb_lock); __clear_hugetlb_destructor(h, folio); spin_unlock_irq(&hugetlb_lock);

11 months, 4 weeks

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2024