November 2022 - Linux-stable-mirror

[merged mm-hotfixes-stable] mm-khugepaged-fix-gup-fast-interaction-by-sending-ipi.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/khugepaged: fix GUP-fast interaction by sending IPI has been removed from the -mm tree. Its filename was mm-khugepaged-fix-gup-fast-interaction-by-sending-ipi.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: Jann Horn <jannh(a)google.com> Subject: mm/khugepaged: fix GUP-fast interaction by sending IPI Date: Fri, 25 Nov 2022 22:37:13 +0100 Since commit 70cbc3cc78a99 ("mm: gup: fix the fast GUP race against THP collapse"), the lockless_pages_from_mm() fastpath rechecks the pmd_t to ensure that the page table was not removed by khugepaged in between. However, lockless_pages_from_mm() still requires that the page table is not concurrently freed. Fix it by sending IPIs (if the architecture uses semi-RCU-style page table freeing) before freeing/reusing page tables. Link: https://lkml.kernel.org/r/20221129154730.2274278-2-jannh@google.com Link: https://lkml.kernel.org/r/20221128180252.1684965-2-jannh@google.com Link: https://lkml.kernel.org/r/20221125213714.4115729-2-jannh@google.com Fixes: ba76149f47d8 ("thp: khugepaged") Signed-off-by: Jann Horn <jannh(a)google.com> Reviewed-by: Yang Shi <shy828301(a)gmail.com> Acked-by: David Hildenbrand <david(a)redhat.com> Cc: John Hubbard <jhubbard(a)nvidia.com> Cc: Peter Xu <peterx(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/asm-generic/tlb.h | 4 ++++ mm/khugepaged.c | 2 ++ mm/mmu_gather.c | 4 +--- 3 files changed, 7 insertions(+), 3 deletions(-) --- a/include/asm-generic/tlb.h~mm-khugepaged-fix-gup-fast-interaction-by-sending-ipi +++ a/include/asm-generic/tlb.h @@ -222,12 +222,16 @@ extern void tlb_remove_table(struct mmu_ #define tlb_needs_table_invalidate() (true) #endif +void tlb_remove_table_sync_one(void); + #else #ifdef tlb_needs_table_invalidate #error tlb_needs_table_invalidate() requires MMU_GATHER_RCU_TABLE_FREE #endif +static inline void tlb_remove_table_sync_one(void) { } + #endif /* CONFIG_MMU_GATHER_RCU_TABLE_FREE */ --- a/mm/khugepaged.c~mm-khugepaged-fix-gup-fast-interaction-by-sending-ipi +++ a/mm/khugepaged.c @@ -1051,6 +1051,7 @@ static int collapse_huge_page(struct mm_ _pmd = pmdp_collapse_flush(vma, address, pmd); spin_unlock(pmd_ptl); mmu_notifier_invalidate_range_end(&range); + tlb_remove_table_sync_one(); spin_lock(pte_ptl); result = __collapse_huge_page_isolate(vma, address, pte, cc, @@ -1410,6 +1411,7 @@ static void collapse_and_free_pmd(struct lockdep_assert_held_write(&vma->anon_vma->root->rwsem); pmd = pmdp_collapse_flush(vma, addr, pmdp); + tlb_remove_table_sync_one(); mm_dec_nr_ptes(mm); page_table_check_pte_clear_range(mm, addr, pmd); pte_free(mm, pmd_pgtable(pmd)); --- a/mm/mmu_gather.c~mm-khugepaged-fix-gup-fast-interaction-by-sending-ipi +++ a/mm/mmu_gather.c @@ -153,7 +153,7 @@ static void tlb_remove_table_smp_sync(vo /* Simply deliver the interrupt */ } -static void tlb_remove_table_sync_one(void) +void tlb_remove_table_sync_one(void) { /* * This isn't an RCU grace period and hence the page-tables cannot be @@ -177,8 +177,6 @@ static void tlb_remove_table_free(struct #else /* !CONFIG_MMU_GATHER_RCU_TABLE_FREE */ -static void tlb_remove_table_sync_one(void) { } - static void tlb_remove_table_free(struct mmu_table_batch *batch) { __tlb_remove_table_free(batch); _ Patches currently in -mm which might be from jannh(a)google.com are

1 year, 11 months

1
0
0 0

[merged mm-hotfixes-stable] mm-khugepaged-take-the-right-locks-for-page-table-retraction.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/khugepaged: take the right locks for page table retraction has been removed from the -mm tree. Its filename was mm-khugepaged-take-the-right-locks-for-page-table-retraction.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: Jann Horn <jannh(a)google.com> Subject: mm/khugepaged: take the right locks for page table retraction Date: Fri, 25 Nov 2022 22:37:12 +0100 pagetable walks on address ranges mapped by VMAs can be done under the mmap lock, the lock of an anon_vma attached to the VMA, or the lock of the VMA's address_space. Only one of these needs to be held, and it does not need to be held in exclusive mode. Under those circumstances, the rules for concurrent access to page table entries are: - Terminal page table entries (entries that don't point to another page table) can be arbitrarily changed under the page table lock, with the exception that they always need to be consistent for hardware page table walks and lockless_pages_from_mm(). This includes that they can be changed into non-terminal entries. - Non-terminal page table entries (which point to another page table) can not be modified; readers are allowed to READ_ONCE() an entry, verify that it is non-terminal, and then assume that its value will stay as-is. Retracting a page table involves modifying a non-terminal entry, so page-table-level locks are insufficient to protect against concurrent page table traversal; it requires taking all the higher-level locks under which it is possible to start a page walk in the relevant range in exclusive mode. The collapse_huge_page() path for anonymous THP already follows this rule, but the shmem/file THP path was getting it wrong, making it possible for concurrent rmap-based operations to cause corruption. Link: https://lkml.kernel.org/r/20221129154730.2274278-1-jannh@google.com Link: https://lkml.kernel.org/r/20221128180252.1684965-1-jannh@google.com Link: https://lkml.kernel.org/r/20221125213714.4115729-1-jannh@google.com Fixes: 27e1f8273113 ("khugepaged: enable collapse pmd for pte-mapped THP") Signed-off-by: Jann Horn <jannh(a)google.com> Reviewed-by: Yang Shi <shy828301(a)gmail.com> Acked-by: David Hildenbrand <david(a)redhat.com> Cc: John Hubbard <jhubbard(a)nvidia.com> Cc: Peter Xu <peterx(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/khugepaged.c | 55 ++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 51 insertions(+), 4 deletions(-) --- a/mm/khugepaged.c~mm-khugepaged-take-the-right-locks-for-page-table-retraction +++ a/mm/khugepaged.c @@ -1379,16 +1379,37 @@ static int set_huge_pmd(struct vm_area_s return SCAN_SUCCEED; } +/* + * A note about locking: + * Trying to take the page table spinlocks would be useless here because those + * are only used to synchronize: + * + * - modifying terminal entries (ones that point to a data page, not to another + * page table) + * - installing *new* non-terminal entries + * + * Instead, we need roughly the same kind of protection as free_pgtables() or + * mm_take_all_locks() (but only for a single VMA): + * The mmap lock together with this VMA's rmap locks covers all paths towards + * the page table entries we're messing with here, except for hardware page + * table walks and lockless_pages_from_mm(). + */ static void collapse_and_free_pmd(struct mm_struct *mm, struct vm_area_struct *vma, unsigned long addr, pmd_t *pmdp) { - spinlock_t *ptl; pmd_t pmd; mmap_assert_write_locked(mm); - ptl = pmd_lock(vma->vm_mm, pmdp); + if (vma->vm_file) + lockdep_assert_held_write(&vma->vm_file->f_mapping->i_mmap_rwsem); + /* + * All anon_vmas attached to the VMA have the same root and are + * therefore locked by the same lock. + */ + if (vma->anon_vma) + lockdep_assert_held_write(&vma->anon_vma->root->rwsem); + pmd = pmdp_collapse_flush(vma, addr, pmdp); - spin_unlock(ptl); mm_dec_nr_ptes(mm); page_table_check_pte_clear_range(mm, addr, pmd); pte_free(mm, pmd_pgtable(pmd)); @@ -1439,6 +1460,14 @@ int collapse_pte_mapped_thp(struct mm_st if (!hugepage_vma_check(vma, vma->vm_flags, false, false, false)) return SCAN_VMA_CHECK; + /* + * Symmetry with retract_page_tables(): Exclude MAP_PRIVATE mappings + * that got written to. Without this, we'd have to also lock the + * anon_vma if one exists. + */ + if (vma->anon_vma) + return SCAN_VMA_CHECK; + /* Keep pmd pgtable for uffd-wp; see comment in retract_page_tables() */ if (userfaultfd_wp(vma)) return SCAN_PTE_UFFD_WP; @@ -1472,6 +1501,20 @@ int collapse_pte_mapped_thp(struct mm_st goto drop_hpage; } + /* + * We need to lock the mapping so that from here on, only GUP-fast and + * hardware page walks can access the parts of the page tables that + * we're operating on. + * See collapse_and_free_pmd(). + */ + i_mmap_lock_write(vma->vm_file->f_mapping); + + /* + * This spinlock should be unnecessary: Nobody else should be accessing + * the page tables under spinlock protection here, only + * lockless_pages_from_mm() and the hardware page walker can access page + * tables while all the high-level locks are held in write mode. + */ start_pte = pte_offset_map_lock(mm, pmd, haddr, &ptl); result = SCAN_FAIL; @@ -1526,6 +1569,8 @@ int collapse_pte_mapped_thp(struct mm_st /* step 4: remove pte entries */ collapse_and_free_pmd(mm, vma, haddr, pmd); + i_mmap_unlock_write(vma->vm_file->f_mapping); + maybe_install_pmd: /* step 5: install pmd entry */ result = install_pmd @@ -1539,6 +1584,7 @@ drop_hpage: abort: pte_unmap_unlock(start_pte, ptl); + i_mmap_unlock_write(vma->vm_file->f_mapping); goto drop_hpage; } @@ -1595,7 +1641,8 @@ static int retract_page_tables(struct ad * An alternative would be drop the check, but check that page * table is clear before calling pmdp_collapse_flush() under * ptl. It has higher chance to recover THP for the VMA, but - * has higher cost too. + * has higher cost too. It would also probably require locking + * the anon_vma. */ if (vma->anon_vma) { result = SCAN_PAGE_ANON; _ Patches currently in -mm which might be from jannh(a)google.com are

1 year, 11 months

1
0
0 0

[merged mm-hotfixes-stable] mm-migrate-fix-thps-mapcount-on-isolation.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm: migrate: fix THP's mapcount on isolation has been removed from the -mm tree. Its filename was mm-migrate-fix-thps-mapcount-on-isolation.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: Gavin Shan <gshan(a)redhat.com> Subject: mm: migrate: fix THP's mapcount on isolation Date: Thu, 24 Nov 2022 17:55:23 +0800 The issue is reported when removing memory through virtio_mem device. The transparent huge page, experienced copy-on-write fault, is wrongly regarded as pinned. The transparent huge page is escaped from being isolated in isolate_migratepages_block(). The transparent huge page can't be migrated and the corresponding memory block can't be put into offline state. Fix it by replacing page_mapcount() with total_mapcount(). With this, the transparent huge page can be isolated and migrated, and the memory block can be put into offline state. Besides, The page's refcount is increased a bit earlier to avoid the page is released when the check is executed. Link: https://lkml.kernel.org/r/20221124095523.31061-1-gshan@redhat.com Fixes: 1da2f328fa64 ("mm,thp,compaction,cma: allow THP migration for CMA allocations") Signed-off-by: Gavin Shan <gshan(a)redhat.com> Reported-by: Zhenyu Zhang <zhenyzha(a)redhat.com> Tested-by: Zhenyu Zhang <zhenyzha(a)redhat.com> Suggested-by: David Hildenbrand <david(a)redhat.com> Acked-by: David Hildenbrand <david(a)redhat.com> Cc: Alistair Popple <apopple(a)nvidia.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: William Kucharski <william.kucharski(a)oracle.com> Cc: Zi Yan <ziy(a)nvidia.com> Cc: <stable(a)vger.kernel.org> [5.7+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/compaction.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) --- a/mm/compaction.c~mm-migrate-fix-thps-mapcount-on-isolation +++ a/mm/compaction.c @@ -985,28 +985,28 @@ isolate_migratepages_block(struct compac } /* + * Be careful not to clear PageLRU until after we're + * sure the page is not being freed elsewhere -- the + * page release code relies on it. + */ + if (unlikely(!get_page_unless_zero(page))) + goto isolate_fail; + + /* * Migration will fail if an anonymous page is pinned in memory, * so avoid taking lru_lock and isolating it unnecessarily in an * admittedly racy check. */ mapping = page_mapping(page); - if (!mapping && page_count(page) > page_mapcount(page)) - goto isolate_fail; + if (!mapping && (page_count(page) - 1) > total_mapcount(page)) + goto isolate_fail_put; /* * Only allow to migrate anonymous pages in GFP_NOFS context * because those do not depend on fs locks. */ if (!(cc->gfp_mask & __GFP_FS) && mapping) - goto isolate_fail; - - /* - * Be careful not to clear PageLRU until after we're - * sure the page is not being freed elsewhere -- the - * page release code relies on it. - */ - if (unlikely(!get_page_unless_zero(page))) - goto isolate_fail; + goto isolate_fail_put; /* Only take pages on LRU: a check now makes later tests safe */ if (!PageLRU(page)) _ Patches currently in -mm which might be from gshan(a)redhat.com are

1 year, 11 months

1
0
0 0

[merged mm-hotfixes-stable] mm-damon-sysfs-fix-wrong-empty-schemes-assumption-under-online-tuning-in-damon_sysfs_set_schemes.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/damon/sysfs: fix wrong empty schemes assumption under online tuning in damon_sysfs_set_schemes() has been removed from the -mm tree. Its filename was mm-damon-sysfs-fix-wrong-empty-schemes-assumption-under-online-tuning-in-damon_sysfs_set_schemes.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: SeongJae Park <sj(a)kernel.org> Subject: mm/damon/sysfs: fix wrong empty schemes assumption under online tuning in damon_sysfs_set_schemes() Date: Tue, 22 Nov 2022 19:48:31 +0000 Commit da87878010e5 ("mm/damon/sysfs: support online inputs update") made 'damon_sysfs_set_schemes()' to be called for running DAMON context, which could have schemes. In the case, DAMON sysfs interface is supposed to update, remove, or add schemes to reflect the sysfs files. However, the code is assuming the DAMON context wouldn't have schemes at all, and therefore creates and adds new schemes. As a result, the code doesn't work as intended for online schemes tuning and could have more than expected memory footprint. The schemes are all in the DAMON context, so it doesn't leak the memory, though. Remove the wrong asssumption (the DAMON context wouldn't have schemes) in 'damon_sysfs_set_schemes()' to fix the bug. Link: https://lkml.kernel.org/r/20221122194831.3472-1-sj@kernel.org Fixes: da87878010e5 ("mm/damon/sysfs: support online inputs update") Signed-off-by: SeongJae Park <sj(a)kernel.org> Cc: <stable(a)vger.kernel.org> [5.19+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/damon/sysfs.c | 46 +++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 44 insertions(+), 2 deletions(-) --- a/mm/damon/sysfs.c~mm-damon-sysfs-fix-wrong-empty-schemes-assumption-under-online-tuning-in-damon_sysfs_set_schemes +++ a/mm/damon/sysfs.c @@ -2283,12 +2283,54 @@ static struct damos *damon_sysfs_mk_sche &wmarks); } +static void damon_sysfs_update_scheme(struct damos *scheme, + struct damon_sysfs_scheme *sysfs_scheme) +{ + struct damon_sysfs_access_pattern *access_pattern = + sysfs_scheme->access_pattern; + struct damon_sysfs_quotas *sysfs_quotas = sysfs_scheme->quotas; + struct damon_sysfs_weights *sysfs_weights = sysfs_quotas->weights; + struct damon_sysfs_watermarks *sysfs_wmarks = sysfs_scheme->watermarks; + + scheme->pattern.min_sz_region = access_pattern->sz->min; + scheme->pattern.max_sz_region = access_pattern->sz->max; + scheme->pattern.min_nr_accesses = access_pattern->nr_accesses->min; + scheme->pattern.max_nr_accesses = access_pattern->nr_accesses->max; + scheme->pattern.min_age_region = access_pattern->age->min; + scheme->pattern.max_age_region = access_pattern->age->max; + + scheme->action = sysfs_scheme->action; + + scheme->quota.ms = sysfs_quotas->ms; + scheme->quota.sz = sysfs_quotas->sz; + scheme->quota.reset_interval = sysfs_quotas->reset_interval_ms; + scheme->quota.weight_sz = sysfs_weights->sz; + scheme->quota.weight_nr_accesses = sysfs_weights->nr_accesses; + scheme->quota.weight_age = sysfs_weights->age; + + scheme->wmarks.metric = sysfs_wmarks->metric; + scheme->wmarks.interval = sysfs_wmarks->interval_us; + scheme->wmarks.high = sysfs_wmarks->high; + scheme->wmarks.mid = sysfs_wmarks->mid; + scheme->wmarks.low = sysfs_wmarks->low; +} + static int damon_sysfs_set_schemes(struct damon_ctx *ctx, struct damon_sysfs_schemes *sysfs_schemes) { - int i; + struct damos *scheme, *next; + int i = 0; + + damon_for_each_scheme_safe(scheme, next, ctx) { + if (i < sysfs_schemes->nr) + damon_sysfs_update_scheme(scheme, + sysfs_schemes->schemes_arr[i]); + else + damon_destroy_scheme(scheme); + i++; + } - for (i = 0; i < sysfs_schemes->nr; i++) { + for (; i < sysfs_schemes->nr; i++) { struct damos *scheme, *next; scheme = damon_sysfs_mk_scheme(sysfs_schemes->schemes_arr[i]); _ Patches currently in -mm which might be from sj(a)kernel.org are mm-damon-core-split-out-damos-charged-region-skip-logic-into-a-new-function.patch mm-damon-core-split-damos-application-logic-into-a-new-function.patch mm-damon-core-split-out-scheme-stat-update-logic-into-a-new-function.patch mm-damon-core-split-out-scheme-quota-adjustment-logic-into-a-new-function.patch mm-damon-sysfs-use-damon_addr_range-for-regions-start-and-end-values.patch mm-damon-sysfs-remove-parameters-of-damon_sysfs_region_alloc.patch mm-damon-sysfs-move-sysfs_lock-to-common-module.patch mm-damon-sysfs-move-unsigned-long-range-directory-to-common-module.patch mm-damon-sysfs-split-out-kdamond-independent-schemes-stats-update-logic-into-a-new-function.patch mm-damon-sysfs-split-out-schemes-directory-implementation-to-separate-file.patch mm-damon-modules-deduplicate-init-steps-for-damon-context-setup.patch mm-damon-reclaimlru_sort-remove-unnecessarily-included-headers.patch mm-damon-reclaim-enable-and-disable-synchronously.patch selftests-damon-add-tests-for-damon_reclaims-enabled-parameter.patch mm-damon-lru_sort-enable-and-disable-synchronously.patch selftests-damon-add-tests-for-damon_lru_sorts-enabled-parameter.patch docs-admin-guide-mm-damon-usage-describe-the-rules-of-sysfs-region-directories.patch docs-admin-guide-mm-damon-usage-fix-wrong-usage-example-of-init_regions-file.patch mm-damon-core-add-a-callback-for-scheme-target-regions-check.patch mm-damon-sysfs-schemes-implement-schemes-tried_regions-directory.patch mm-damon-sysfs-schemes-implement-scheme-region-directory.patch mm-damon-sysfs-implement-damos-tried-regions-update-command.patch mm-damon-sysfs-implement-damos-tried-regions-update-command-fix.patch mm-damon-sysfs-schemes-implement-damos-tried-regions-clear-command.patch mm-damon-sysfs-schemes-implement-damos-tried-regions-clear-command-fix.patch tools-selftets-damon-sysfs-test-tried_regions-directory-existence.patch docs-admin-guide-mm-damon-usage-document-schemes-s-tried_regions-sysfs-directory.patch docs-abi-damon-document-schemes-s-tried_regions-sysfs-directory.patch selftests-damon-test-non-context-inputs-to-rm_contexts-file.patch

1 year, 11 months

1
0
0 0

[merged mm-hotfixes-stable] tools-vm-slabinfo-gnuplot-use-grep-e-instead-of-egrep.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: tools/vm/slabinfo-gnuplot: use "grep -E" instead of "egrep" has been removed from the -mm tree. Its filename was tools-vm-slabinfo-gnuplot-use-grep-e-instead-of-egrep.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: Tiezhu Yang <yangtiezhu(a)loongson.cn> Subject: tools/vm/slabinfo-gnuplot: use "grep -E" instead of "egrep" Date: Sat, 19 Nov 2022 10:36:59 +0800 The latest version of grep claims the egrep is now obsolete so the build now contains warnings that look like: egrep: warning: egrep is obsolescent; using grep -E fix this up by moving the related file to use "grep -E" instead. sed -i "s/egrep/grep -E/g" `grep egrep -rwl tools/vm` Here are the steps to install the latest grep: wget http://ftp.gnu.org/gnu/grep/grep-3.8.tar.gz tar xf grep-3.8.tar.gz cd grep-3.8 && ./configure && make sudo make install export PATH=/usr/local/bin:$PATH Link: https://lkml.kernel.org/r/1668825419-30584-1-git-send-email-yangtiezhu@loon… Signed-off-by: Tiezhu Yang <yangtiezhu(a)loongson.cn> Reviewed-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/vm/slabinfo-gnuplot.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/tools/vm/slabinfo-gnuplot.sh~tools-vm-slabinfo-gnuplot-use-grep-e-instead-of-egrep +++ a/tools/vm/slabinfo-gnuplot.sh @@ -150,7 +150,7 @@ do_preprocess() let lines=3 out=`basename "$in"`"-slabs-by-loss" `cat "$in" | grep -A "$lines" 'Slabs sorted by loss' |\ - egrep -iv '\-\-|Name|Slabs'\ + grep -E -iv '\-\-|Name|Slabs'\ | awk '{print $1" "$4+$2*$3" "$4}' > "$out"` if [ $? -eq 0 ]; then do_slabs_plotting "$out" @@ -159,7 +159,7 @@ do_preprocess() let lines=3 out=`basename "$in"`"-slabs-by-size" `cat "$in" | grep -A "$lines" 'Slabs sorted by size' |\ - egrep -iv '\-\-|Name|Slabs'\ + grep -E -iv '\-\-|Name|Slabs'\ | awk '{print $1" "$4" "$4-$2*$3}' > "$out"` if [ $? -eq 0 ]; then do_slabs_plotting "$out" _ Patches currently in -mm which might be from yangtiezhu(a)loongson.cn are

1 year, 11 months

1
0
0 0

[merged mm-hotfixes-stable] nilfs2-fix-null-pointer-dereference-in-nilfs_palloc_commit_free_entry.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry() has been removed from the -mm tree. Its filename was nilfs2-fix-null-pointer-dereference-in-nilfs_palloc_commit_free_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: ZhangPeng <zhangpeng362(a)huawei.com> Subject: nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry() Date: Sat, 19 Nov 2022 21:05:42 +0900 Syzbot reported a null-ptr-deref bug: NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 PID: 3603 Comm: segctord Not tainted 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0 fs/nilfs2/alloc.c:608 Code: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 26 05 00 00 49 8b 46 10 be a6 00 00 00 48 c7 c7 RSP: 0018:ffffc90003dff830 EFLAGS: 00010212 RAX: dffffc0000000000 RBX: ffff88802594e218 RCX: 000000000000000d RDX: 0000000000000002 RSI: 0000000000002000 RDI: 0000000000000010 RBP: ffff888071880222 R08: 0000000000000005 R09: 000000000000003f R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158 R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004 FS: 0000000000000000(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0 Call Trace: <TASK> nilfs_dat_commit_free fs/nilfs2/dat.c:114 [inline] nilfs_dat_commit_end+0x464/0x5f0 fs/nilfs2/dat.c:193 nilfs_dat_commit_update+0x26/0x40 fs/nilfs2/dat.c:236 nilfs_btree_commit_update_v+0x87/0x4a0 fs/nilfs2/btree.c:1940 nilfs_btree_commit_propagate_v fs/nilfs2/btree.c:2016 [inline] nilfs_btree_propagate_v fs/nilfs2/btree.c:2046 [inline] nilfs_btree_propagate+0xa00/0xd60 fs/nilfs2/btree.c:2088 nilfs_bmap_propagate+0x73/0x170 fs/nilfs2/bmap.c:337 nilfs_collect_file_data+0x45/0xd0 fs/nilfs2/segment.c:568 nilfs_segctor_apply_buffers+0x14a/0x470 fs/nilfs2/segment.c:1018 nilfs_segctor_scan_file+0x3f4/0x6f0 fs/nilfs2/segment.c:1067 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1197 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1503 [inline] nilfs_segctor_do_construct+0x12fc/0x6af0 fs/nilfs2/segment.c:2045 nilfs_segctor_construct+0x8e3/0xb30 fs/nilfs2/segment.c:2379 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2487 [inline] nilfs_segctor_thread+0x3c3/0xf30 fs/nilfs2/segment.c:2570 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> ... If DAT metadata file is corrupted on disk, there is a case where req->pr_desc_bh is NULL and blocknr is 0 at nilfs_dat_commit_end() during a b-tree operation that cascadingly updates ancestor nodes of the b-tree, because nilfs_dat_commit_alloc() for a lower level block can initialize the blocknr on the same DAT entry between nilfs_dat_prepare_end() and nilfs_dat_commit_end(). If this happens, nilfs_dat_commit_end() calls nilfs_dat_commit_free() without valid buffer heads in req->pr_desc_bh and req->pr_bitmap_bh, and causes the NULL pointer dereference above in nilfs_palloc_commit_free_entry() function, which leads to a crash. Fix this by adding a NULL check on req->pr_desc_bh and req->pr_bitmap_bh before nilfs_palloc_commit_free_entry() in nilfs_dat_commit_free(). This also calls nilfs_error() in that case to notify that there is a fatal flaw in the filesystem metadata and prevent further operations. Link: https://lkml.kernel.org/r/00000000000097c20205ebaea3d6@google.com Link: https://lkml.kernel.org/r/20221114040441.1649940-1-zhangpeng362@huawei.com Link: https://lkml.kernel.org/r/20221119120542.17204-1-konishi.ryusuke@gmail.com Signed-off-by: ZhangPeng <zhangpeng362(a)huawei.com> Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Reported-by: syzbot+ebe05ee8e98f755f61d0(a)syzkaller.appspotmail.com Tested-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/nilfs2/dat.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/fs/nilfs2/dat.c~nilfs2-fix-null-pointer-dereference-in-nilfs_palloc_commit_free_entry +++ a/fs/nilfs2/dat.c @@ -111,6 +111,13 @@ static void nilfs_dat_commit_free(struct kunmap_atomic(kaddr); nilfs_dat_commit_entry(dat, req); + + if (unlikely(req->pr_desc_bh == NULL || req->pr_bitmap_bh == NULL)) { + nilfs_error(dat->i_sb, + "state inconsistency probably due to duplicate use of vblocknr = %llu", + (unsigned long long)req->pr_entry_nr); + return; + } nilfs_palloc_commit_free_entry(dat, req); } _ Patches currently in -mm which might be from zhangpeng362(a)huawei.com are hfs-fix-oob-read-in-__hfs_brec_find.patch

1 year, 11 months

1
0
0 0

[merged mm-hotfixes-stable] hugetlb-dont-delete-vma_lock-in-hugetlb-madv_dontneed-processing.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: hugetlb: don't delete vma_lock in hugetlb MADV_DONTNEED processing has been removed from the -mm tree. Its filename was hugetlb-dont-delete-vma_lock-in-hugetlb-madv_dontneed-processing.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: Mike Kravetz <mike.kravetz(a)oracle.com> Subject: hugetlb: don't delete vma_lock in hugetlb MADV_DONTNEED processing Date: Mon, 14 Nov 2022 15:55:06 -0800 madvise(MADV_DONTNEED) ends up calling zap_page_range() to clear page tables associated with the address range. For hugetlb vmas, zap_page_range will call __unmap_hugepage_range_final. However, __unmap_hugepage_range_final assumes the passed vma is about to be removed and deletes the vma_lock to prevent pmd sharing as the vma is on the way out. In the case of madvise(MADV_DONTNEED) the vma remains, but the missing vma_lock prevents pmd sharing and could potentially lead to issues with truncation/fault races. This issue was originally reported here [1] as a BUG triggered in page_try_dup_anon_rmap. Prior to the introduction of the hugetlb vma_lock, __unmap_hugepage_range_final cleared the VM_MAYSHARE flag to prevent pmd sharing. Subsequent faults on this vma were confused as VM_MAYSHARE indicates a sharable vma, but was not set so page_mapping was not set in new pages added to the page table. This resulted in pages that appeared anonymous in a VM_SHARED vma and triggered the BUG. Address issue by adding a new zap flag ZAP_FLAG_UNMAP to indicate an unmap call from unmap_vmas(). This is used to indicate the 'final' unmapping of a hugetlb vma. When called via MADV_DONTNEED, this flag is not set and the vm_lock is not deleted. [1] https://lore.kernel.org/lkml/CAO4mrfdLMXsao9RF4fUE8-Wfde8xmjsKrTNMNC9wjUb6J… Link: https://lkml.kernel.org/r/20221114235507.294320-3-mike.kravetz@oracle.com Fixes: 90e7e7f5ef3f ("mm: enable MADV_DONTNEED for hugetlb mappings") Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com> Reported-by: Wei Chen <harperchen1110(a)gmail.com> Cc: Axel Rasmussen <axelrasmussen(a)google.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Mina Almasry <almasrymina(a)google.com> Cc: Nadav Amit <nadav.amit(a)gmail.com> Cc: Naoya Horiguchi <naoya.horiguchi(a)linux.dev> Cc: Peter Xu <peterx(a)redhat.com> Cc: Rik van Riel <riel(a)surriel.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/mm.h | 2 ++ mm/hugetlb.c | 27 ++++++++++++++++----------- mm/memory.c | 2 +- 3 files changed, 19 insertions(+), 12 deletions(-) --- a/include/linux/mm.h~hugetlb-dont-delete-vma_lock-in-hugetlb-madv_dontneed-processing +++ a/include/linux/mm.h @@ -1868,6 +1868,8 @@ struct zap_details { * default, the flag is not set. */ #define ZAP_FLAG_DROP_MARKER ((__force zap_flags_t) BIT(0)) +/* Set in unmap_vmas() to indicate a final unmap call. Only used by hugetlb */ +#define ZAP_FLAG_UNMAP ((__force zap_flags_t) BIT(1)) #ifdef CONFIG_MMU extern bool can_do_mlock(void); --- a/mm/hugetlb.c~hugetlb-dont-delete-vma_lock-in-hugetlb-madv_dontneed-processing +++ a/mm/hugetlb.c @@ -5206,17 +5206,22 @@ void __unmap_hugepage_range_final(struct __unmap_hugepage_range(tlb, vma, start, end, ref_page, zap_flags); - /* - * Unlock and free the vma lock before releasing i_mmap_rwsem. When - * the vma_lock is freed, this makes the vma ineligible for pmd - * sharing. And, i_mmap_rwsem is required to set up pmd sharing. - * This is important as page tables for this unmapped range will - * be asynchrously deleted. If the page tables are shared, there - * will be issues when accessed by someone else. - */ - __hugetlb_vma_unlock_write_free(vma); - - i_mmap_unlock_write(vma->vm_file->f_mapping); + if (zap_flags & ZAP_FLAG_UNMAP) { /* final unmap */ + /* + * Unlock and free the vma lock before releasing i_mmap_rwsem. + * When the vma_lock is freed, this makes the vma ineligible + * for pmd sharing. And, i_mmap_rwsem is required to set up + * pmd sharing. This is important as page tables for this + * unmapped range will be asynchrously deleted. If the page + * tables are shared, there will be issues when accessed by + * someone else. + */ + __hugetlb_vma_unlock_write_free(vma); + i_mmap_unlock_write(vma->vm_file->f_mapping); + } else { + i_mmap_unlock_write(vma->vm_file->f_mapping); + hugetlb_vma_unlock_write(vma); + } } void unmap_hugepage_range(struct vm_area_struct *vma, unsigned long start, --- a/mm/memory.c~hugetlb-dont-delete-vma_lock-in-hugetlb-madv_dontneed-processing +++ a/mm/memory.c @@ -1711,7 +1711,7 @@ void unmap_vmas(struct mmu_gather *tlb, { struct mmu_notifier_range range; struct zap_details details = { - .zap_flags = ZAP_FLAG_DROP_MARKER, + .zap_flags = ZAP_FLAG_DROP_MARKER | ZAP_FLAG_UNMAP, /* Careful - we need to zap private pages too! */ .even_cows = true, }; _ Patches currently in -mm which might be from mike.kravetz(a)oracle.com are selftests-vm-update-hugetlb-madvise.patch hugetlb-remove-duplicate-mmu-notifications.patch

1 year, 11 months

1
0
0 0

[merged mm-hotfixes-stable] madvise-use-zap_page_range_single-for-madvise-dontneed.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: madvise: use zap_page_range_single for madvise dontneed has been removed from the -mm tree. Its filename was madvise-use-zap_page_range_single-for-madvise-dontneed.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: Mike Kravetz <mike.kravetz(a)oracle.com> Subject: madvise: use zap_page_range_single for madvise dontneed Date: Mon, 14 Nov 2022 15:55:05 -0800 This series addresses the issue first reported in [1], and fully described in patch 2. Patches 1 and 2 address the user visible issue and are tagged for stable backports. While exploring solutions to this issue, related problems with mmu notification calls were discovered. This is addressed in the patch "hugetlb: remove duplicate mmu notifications:". Since there are no user visible effects, this third is not tagged for stable backports. Previous discussions suggested further cleanup by removing the routine zap_page_range. This is possible because zap_page_range_single is now exported, and all callers of zap_page_range pass ranges entirely within a single vma. This work will be done in a later patch so as not to distract from this bug fix. [1] https://lore.kernel.org/lkml/CAO4mrfdLMXsao9RF4fUE8-Wfde8xmjsKrTNMNC9wjUb6J… This patch (of 2): Expose the routine zap_page_range_single to zap a range within a single vma. The madvise routine madvise_dontneed_single_vma can use this routine as it explicitly operates on a single vma. Also, update the mmu notification range in zap_page_range_single to take hugetlb pmd sharing into account. This is required as MADV_DONTNEED supports hugetlb vmas. Link: https://lkml.kernel.org/r/20221114235507.294320-1-mike.kravetz@oracle.com Link: https://lkml.kernel.org/r/20221114235507.294320-2-mike.kravetz@oracle.com Fixes: 90e7e7f5ef3f ("mm: enable MADV_DONTNEED for hugetlb mappings") Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com> Reported-by: Wei Chen <harperchen1110(a)gmail.com> Cc: Axel Rasmussen <axelrasmussen(a)google.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Mina Almasry <almasrymina(a)google.com> Cc: Nadav Amit <nadav.amit(a)gmail.com> Cc: Naoya Horiguchi <naoya.horiguchi(a)linux.dev> Cc: Peter Xu <peterx(a)redhat.com> Cc: Rik van Riel <riel(a)surriel.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/mm.h | 27 +++++++++++++++++++-------- mm/madvise.c | 6 +++--- mm/memory.c | 23 +++++++++++------------ 3 files changed, 33 insertions(+), 23 deletions(-) --- a/include/linux/mm.h~madvise-use-zap_page_range_single-for-madvise-dontneed +++ a/include/linux/mm.h @@ -1852,6 +1852,23 @@ static void __maybe_unused show_free_are __show_free_areas(flags, nodemask, MAX_NR_ZONES - 1); } +/* + * Parameter block passed down to zap_pte_range in exceptional cases. + */ +struct zap_details { + struct folio *single_folio; /* Locked folio to be unmapped */ + bool even_cows; /* Zap COWed private pages too? */ + zap_flags_t zap_flags; /* Extra flags for zapping */ +}; + +/* + * Whether to drop the pte markers, for example, the uffd-wp information for + * file-backed memory. This should only be specified when we will completely + * drop the page in the mm, either by truncation or unmapping of the vma. By + * default, the flag is not set. + */ +#define ZAP_FLAG_DROP_MARKER ((__force zap_flags_t) BIT(0)) + #ifdef CONFIG_MMU extern bool can_do_mlock(void); #else @@ -1869,6 +1886,8 @@ void zap_vma_ptes(struct vm_area_struct unsigned long size); void zap_page_range(struct vm_area_struct *vma, unsigned long address, unsigned long size); +void zap_page_range_single(struct vm_area_struct *vma, unsigned long address, + unsigned long size, struct zap_details *details); void unmap_vmas(struct mmu_gather *tlb, struct maple_tree *mt, struct vm_area_struct *start_vma, unsigned long start, unsigned long end); @@ -3467,12 +3486,4 @@ madvise_set_anon_name(struct mm_struct * } #endif -/* - * Whether to drop the pte markers, for example, the uffd-wp information for - * file-backed memory. This should only be specified when we will completely - * drop the page in the mm, either by truncation or unmapping of the vma. By - * default, the flag is not set. - */ -#define ZAP_FLAG_DROP_MARKER ((__force zap_flags_t) BIT(0)) - #endif /* _LINUX_MM_H */ --- a/mm/madvise.c~madvise-use-zap_page_range_single-for-madvise-dontneed +++ a/mm/madvise.c @@ -772,8 +772,8 @@ static int madvise_free_single_vma(struc * Application no longer needs these pages. If the pages are dirty, * it's OK to just throw them away. The app will be more careful about * data it wants to keep. Be sure to free swap resources too. The - * zap_page_range call sets things up for shrink_active_list to actually free - * these pages later if no one else has touched them in the meantime, + * zap_page_range_single call sets things up for shrink_active_list to actually + * free these pages later if no one else has touched them in the meantime, * although we could add these pages to a global reuse list for * shrink_active_list to pick up before reclaiming other pages. * @@ -790,7 +790,7 @@ static int madvise_free_single_vma(struc static long madvise_dontneed_single_vma(struct vm_area_struct *vma, unsigned long start, unsigned long end) { - zap_page_range(vma, start, end - start); + zap_page_range_single(vma, start, end - start, NULL); return 0; } --- a/mm/memory.c~madvise-use-zap_page_range_single-for-madvise-dontneed +++ a/mm/memory.c @@ -1341,15 +1341,6 @@ copy_page_range(struct vm_area_struct *d return ret; } -/* - * Parameter block passed down to zap_pte_range in exceptional cases. - */ -struct zap_details { - struct folio *single_folio; /* Locked folio to be unmapped */ - bool even_cows; /* Zap COWed private pages too? */ - zap_flags_t zap_flags; /* Extra flags for zapping */ -}; - /* Whether we should zap all COWed (private) pages too */ static inline bool should_zap_cows(struct zap_details *details) { @@ -1774,19 +1765,27 @@ void zap_page_range(struct vm_area_struc * * The range must fit into one VMA. */ -static void zap_page_range_single(struct vm_area_struct *vma, unsigned long address, +void zap_page_range_single(struct vm_area_struct *vma, unsigned long address, unsigned long size, struct zap_details *details) { + const unsigned long end = address + size; struct mmu_notifier_range range; struct mmu_gather tlb; lru_add_drain(); mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm, - address, address + size); + address, end); + if (is_vm_hugetlb_page(vma)) + adjust_range_if_pmd_sharing_possible(vma, &range.start, + &range.end); tlb_gather_mmu(&tlb, vma->vm_mm); update_hiwater_rss(vma->vm_mm); mmu_notifier_invalidate_range_start(&range); - unmap_single_vma(&tlb, vma, address, range.end, details); + /* + * unmap 'address-end' not 'range.start-range.end' as range + * could have been expanded for hugetlb pmd sharing. + */ + unmap_single_vma(&tlb, vma, address, end, details); mmu_notifier_invalidate_range_end(&range); tlb_finish_mmu(&tlb); } _ Patches currently in -mm which might be from mike.kravetz(a)oracle.com are selftests-vm-update-hugetlb-madvise.patch hugetlb-remove-duplicate-mmu-notifications.patch

1 year, 11 months

1
0
0 0

[PATCH v2] mm: set the vma flags dirty before testing if it is mergeable

by Muhammad Usama Anjum

The VM_SOFTDIRTY should be set in the vma flags to be tested if new allocation should be merged in previous vma or not. With this patch, the new allocations are merged in the previous VMAs. I've tested it by reverting the commit 34228d473efe ("mm: ignore VM_SOFTDIRTY on VMA merging") and after adding this following patch, I'm seeing that all the new allocations done through mmap() are merged in the previous VMAs. The number of VMAs doesn't increase drastically which had contributed to the crash of gimp. If I run the same test after reverting and not including this patch, the number of VMAs keep on increasing with every mmap() syscall which proves this patch. The commit 34228d473efe ("mm: ignore VM_SOFTDIRTY on VMA merging") seems like a workaround. But it lets the soft-dirty and non-soft-dirty VMA to get merged. It helps in avoiding the creation of too many VMAs. But it creates the problem while adding the feature of clearing the soft-dirty status of only a part of the memory region. Cc: <stable(a)vger.kernel.org> Fixes: d9104d1ca966 ("mm: track vma changes with VM_SOFTDIRTY bit") Signed-off-by: Muhammad Usama Anjum <usama.anjum(a)collabora.com> --- We need more testing of this patch. While implementing clear soft-dirty bit for a range of address space, I'm facing an issue. The non-soft dirty VMA gets merged sometimes with the soft dirty VMA. Thus the non-soft dirty VMA become dirty which is undesirable. When discussed with the some other developers they consider it the regression. Why the non-soft dirty page should appear as soft dirty when it isn't soft dirty in reality? I agree with them. Should we revert 34228d473efe or find a workaround in the IOCTL? * Revert may cause the VMAs to expand in uncontrollable situation where the soft dirty bit of a lot of memory regions or the whole address space is being cleared again and again. AFAIK normal process must either be only clearing a few memory regions. So the applications should be okay. There is still chance of regressions if some applications are already using the soft-dirty bit. I'm not sure how to test it. * Add a flag in the IOCTL to ignore the dirtiness of VMA. The user will surely lose the functionality to detect reused memory regions. But the extraneous soft-dirty pages would not appear. I'm trying to do this in the patch series [1]. Some discussion is going on that this fails with some mprotect use case [2]. I still need to have a look at the mprotect selftest to see how and why this fails. I think this can be implemented after some more work probably in mprotect side. [1] https://lore.kernel.org/all/20221109102303.851281-1-usama.anjum@collabora.c… [2] https://lore.kernel.org/all/bfcae708-db21-04b4-0bbe-712badd03071@redhat.com/ Changes in v2: - Rebase on top of next-20221122 --- mm/mmap.c | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/mm/mmap.c b/mm/mmap.c index f4e2989be5ff..031d23bc43c4 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -2552,6 +2552,15 @@ unsigned long mmap_region(struct file *file, unsigned long addr, vm_flags |= VM_ACCOUNT; } + /* + * New (or expanded) vma always get soft dirty status. + * Otherwise user-space soft-dirty page tracker won't + * be able to distinguish situation when vma area unmapped, + * then new mapped in-place (which must be aimed as + * a completely new data area). + */ + vm_flags |= VM_SOFTDIRTY; + next = mas_next(&mas, ULONG_MAX); prev = mas_prev(&mas, 0); if (vm_flags & VM_SPECIAL) @@ -2724,15 +2733,6 @@ unsigned long mmap_region(struct file *file, unsigned long addr, if (file) uprobe_mmap(vma); - /* - * New (or expanded) vma always get soft dirty status. - * Otherwise user-space soft-dirty page tracker won't - * be able to distinguish situation when vma area unmapped, - * then new mapped in-place (which must be aimed as - * a completely new data area). - */ - vma->vm_flags |= VM_SOFTDIRTY; - vma_set_page_prot(vma); validate_mm(mm); @@ -2974,7 +2974,7 @@ static int do_brk_flags(struct ma_state *mas, struct vm_area_struct *vma, vma->vm_start = addr; vma->vm_end = addr + len; vma->vm_pgoff = addr >> PAGE_SHIFT; - vma->vm_flags = flags; + vma->vm_flags = flags | VM_SOFTDIRTY; vma->vm_page_prot = vm_get_page_prot(flags); mas_set_range(mas, vma->vm_start, addr + len - 1); if (mas_store_gfp(mas, vma, GFP_KERNEL)) @@ -2987,7 +2987,6 @@ static int do_brk_flags(struct ma_state *mas, struct vm_area_struct *vma, mm->data_vm += len >> PAGE_SHIFT; if (flags & VM_LOCKED) mm->locked_vm += (len >> PAGE_SHIFT); - vma->vm_flags |= VM_SOFTDIRTY; validate_mm(mm); return 0; @@ -3021,6 +3020,8 @@ int vm_brk_flags(unsigned long addr, unsigned long request, unsigned long flags) if ((flags & (~VM_EXEC)) != 0) return -EINVAL; + flags |= VM_SOFTDIRTY; + ret = check_brk_limits(addr, len); if (ret) goto limits_failed; -- 2.30.2

1 year, 11 months

2
3
0 0

stable-rc/queue/4.9 baseline: 85 runs, 16 regressions (v4.9.333-106-gf54f8d6bf1c2)

by kernelci.org bot

stable-rc/queue/4.9 baseline: 85 runs, 16 regressions (v4.9.333-106-gf54f8d6bf1c2) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+--------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-baylibre | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2 | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-baylibre | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3 | arm64 | lab-baylibre | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3 | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-baylibre | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F4.9/kernel/v4.9.333-… Test: baseline Tree: stable-rc Branch: queue/4.9 Describe: v4.9.333-106-gf54f8d6bf1c2 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: f54f8d6bf1c266e9cdb5e6f032b1e2fab5e322e2 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+--------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-baylibre | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/638780d0255a6648672abcfa Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… HTML log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/638780d0255a6648672abcfb failing since 204 days (last pass: v4.9.312-43-g5b8113699dd5, first fail: v4.9.312-64-g69b9f3e8fce2) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+--------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/6387813de09b4dad4e2abd26 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… HTML log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/6387813de09b4dad4e2abd27 failing since 204 days (last pass: v4.9.312-43-g8ccd2ae24f47, first fail: v4.9.312-64-g69b9f3e8fce2) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+--------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/638782a593ee4c63ce2abcfa Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… HTML log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/638782a593ee4c63ce2abcfb failing since 204 days (last pass: v4.9.312-43-g5b8113699dd5, first fail: v4.9.312-64-g69b9f3e8fce2) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+--------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/638783e6b5ff5aec9a2abd0e Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… HTML log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/638783e6b5ff5aec9a2abd0f failing since 204 days (last pass: v4.9.312-43-g8ccd2ae24f47, first fail: v4.9.312-64-g69b9f3e8fce2) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+--------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-baylibre | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/638780c40daaf99b792abcfd Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… HTML log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/638780c50daaf99b792abcfe failing since 204 days (last pass: v4.9.312-43-g5b8113699dd5, first fail: v4.9.312-64-g69b9f3e8fce2) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+--------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/63878137e04910a7e22abcfc Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… HTML log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63878137e04910a7e22abcfd failing since 204 days (last pass: v4.9.312-43-g8ccd2ae24f47, first fail: v4.9.312-64-g69b9f3e8fce2) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+--------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/6387827c3a4942859b2abd1c Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… HTML log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/6387827c3a4942859b2abd1d failing since 204 days (last pass: v4.9.312-43-g5b8113699dd5, first fail: v4.9.312-64-g69b9f3e8fce2) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+--------------+----------+----------------------------+------------ qemu_arm64-virt-gicv2-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/638783a85e6621cca12abd1e Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… HTML log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/638783a85e6621cca12abd1f failing since 204 days (last pass: v4.9.312-43-g8ccd2ae24f47, first fail: v4.9.312-64-g69b9f3e8fce2) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+--------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-baylibre | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/638780c231f542246c2abd0b Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… HTML log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/638780c231f542246c2abd0c failing since 204 days (last pass: v4.9.312-43-g5b8113699dd5, first fail: v4.9.312-64-g69b9f3e8fce2) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+--------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/6387813be09b4dad4e2abd21 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… HTML log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/6387813be09b4dad4e2abd22 failing since 204 days (last pass: v4.9.312-43-g8ccd2ae24f47, first fail: v4.9.312-64-g69b9f3e8fce2) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+--------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/638782680a648bd9682abd6a Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… HTML log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/638782680a648bd9682abd6b failing since 204 days (last pass: v4.9.312-43-g5b8113699dd5, first fail: v4.9.312-64-g69b9f3e8fce2) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+--------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3 | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/638783e4fa31ff88562abd03 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… HTML log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/638783e4fa31ff88562abd04 failing since 204 days (last pass: v4.9.312-43-g8ccd2ae24f47, first fail: v4.9.312-64-g69b9f3e8fce2) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+--------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-baylibre | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/638780cf0daaf99b792abd1e Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… HTML log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/638780cf0daaf99b792abd1f failing since 204 days (last pass: v4.9.312-43-g5b8113699dd5, first fail: v4.9.312-64-g69b9f3e8fce2) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+--------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-baylibre | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/63878138f4e53b8fe62abd0e Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… HTML log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/63878138f4e53b8fe62abd0f failing since 204 days (last pass: v4.9.312-43-g8ccd2ae24f47, first fail: v4.9.312-64-g69b9f3e8fce2) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+--------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig | 1 Details: https://kernelci.org/test/plan/id/638782a46851a85e052abd24 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… HTML log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/638782a46851a85e052abd25 failing since 204 days (last pass: v4.9.312-43-g5b8113699dd5, first fail: v4.9.312-64-g69b9f3e8fce2) platform | arch | lab | compiler | defconfig | regressions ---------------------------+-------+--------------+----------+----------------------------+------------ qemu_arm64-virt-gicv3-uefi | arm64 | lab-broonie | gcc-10 | defconfig+arm64-chromebook | 1 Details: https://kernelci.org/test/plan/id/638783d0f5df4472912abd08 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… HTML log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.333-106-gf54f8d6bf1c… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/buildroot-baseline/2022… * baseline.login: https://kernelci.org/test/case/id/638783d0f5df4472912abd09 failing since 204 days (last pass: v4.9.312-43-g8ccd2ae24f47, first fail: v4.9.312-64-g69b9f3e8fce2)

1 year, 11 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2022