November 2022 - Linux-stable-mirror

[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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 months

1
0
0 0

[PATCH v2 0/6] drm/gud: Use the shadow plane helper

by Noralf Trønnes via B4 Submission Endpoint

Hi, I have started to look at igt for testing and want to use CRC tests. To implement support for this I need to move away from the simple kms helper. When looking around for examples I came across Thomas' nice shadow helper and thought, yes this is perfect for drm/gud. So I'll switch to that before I move away from the simple kms helper. The async framebuffer flushing code path now uses a shadow buffer and doesn't touch the framebuffer when it shouldn't. I have also taken the opportunity to inline the synchronous flush code path and make this the default flushing stategy. Noralf. Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: dri-devel(a)lists.freedesktop.org Signed-off-by: Noralf Trønnes <noralf(a)tronnes.org> --- Changes in v2: - Drop patch (Thomas): drm/gem: shadow_fb_access: Prepare imported buffers for CPU access - Use src as variable name for iosys_map (Thomas) - Prepare imported buffer for CPU access in the driver (Thomas) - New patch: make sync flushing the default (Thomas) - Link to v1: https://lore.kernel.org/r/20221122-gud-shadow-plane-v1-0-9de3afa3383e@tronn… --- Noralf Trønnes (6): drm/gud: Fix UBSAN warning drm/gud: Don't retry a failed framebuffer flush drm/gud: Split up gud_flush_work() drm/gud: Prepare buffer for CPU access in gud_flush_work() drm/gud: Use the shadow plane helper drm/gud: Enable synchronous flushing by default drivers/gpu/drm/gud/gud_drv.c | 1 + drivers/gpu/drm/gud/gud_internal.h | 1 + drivers/gpu/drm/gud/gud_pipe.c | 222 ++++++++++++++++++------------------- 3 files changed, 112 insertions(+), 112 deletions(-) --- base-commit: 7257702951305b1f0259c3468c39fc59d1ad4d8b change-id: 20221122-gud-shadow-plane-ae37a95d4d8d Best regards, -- Noralf Trønnes <noralf(a)tronnes.org>

1 year, 5 months

1
6
0 0

Re: [PATCH 6.0 000/289] 6.0.11-rc1 review

by Ronald Warsow

Hi Greg 6.0.11-rc1 compiles, boots and runs here on x86_64 (Intel i5-11400, Fedora 37) Thanks Tested-by: Ronald Warsow <rwarsow(a)gmx.de>

1 year, 5 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2022