December 2024 - Linux-stable-mirror

+ ocfs2-handle-a-symlink-read-error-correctly.patch added to mm-nonmm-unstable branch

by Andrew Morton

The patch titled Subject: ocfs2: handle a symlink read error correctly has been added to the -mm mm-nonmm-unstable branch. Its filename is ocfs2-handle-a-symlink-read-error-correctly.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-nonmm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: "Matthew Wilcox (Oracle)" <willy(a)infradead.org> Subject: ocfs2: handle a symlink read error correctly Date: Thu, 5 Dec 2024 17:16:29 +0000 Patch series "Convert ocfs2 to use folios". Mark did a conversion of ocfs2 to use folios and sent it to me as a giant patch for review ;-) So I've redone it as individual patches, and credited Mark for the patches where his code is substantially the same. It's not a bad way to do it; his patch had some bugs and my patches had some bugs. Hopefully all our bugs were different from each other. And hopefully Mark likes all the changes I made to his code! This patch (of 23): If we can't read the buffer, be sure to unlock the page before returning. Link: https://lkml.kernel.org/r/20241205171653.3179945-1-willy@infradead.org Link: https://lkml.kernel.org/r/20241205171653.3179945-2-willy@infradead.org Signed-off-by: Matthew Wilcox (Oracle) <willy(a)infradead.org> Reviewed-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: Jun Piao <piaojun(a)huawei.com> Cc: Mark Tinguely <mark.tinguely(a)oracle.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/ocfs2/symlink.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/fs/ocfs2/symlink.c~ocfs2-handle-a-symlink-read-error-correctly +++ a/fs/ocfs2/symlink.c @@ -65,7 +65,7 @@ static int ocfs2_fast_symlink_read_folio if (status < 0) { mlog_errno(status); - return status; + goto out; } fe = (struct ocfs2_dinode *) bh->b_data; @@ -76,9 +76,10 @@ static int ocfs2_fast_symlink_read_folio memcpy(kaddr, link, len + 1); kunmap_atomic(kaddr); SetPageUptodate(page); +out: unlock_page(page); brelse(bh); - return 0; + return status; } const struct address_space_operations ocfs2_fast_symlink_aops = { _ Patches currently in -mm which might be from willy(a)infradead.org are vmalloc-fix-accounting-with-i915.patch mm-page_alloc-cache-page_zone-result-in-free_unref_page.patch mm-make-alloc_pages_mpol-static.patch mm-page_alloc-export-free_frozen_pages-instead-of-free_unref_page.patch mm-page_alloc-move-set_page_refcounted-to-callers-of-post_alloc_hook.patch mm-page_alloc-move-set_page_refcounted-to-callers-of-prep_new_page.patch mm-page_alloc-move-set_page_refcounted-to-callers-of-get_page_from_freelist.patch mm-page_alloc-move-set_page_refcounted-to-callers-of-__alloc_pages_cpuset_fallback.patch mm-page_alloc-move-set_page_refcounted-to-callers-of-__alloc_pages_may_oom.patch mm-page_alloc-move-set_page_refcounted-to-callers-of-__alloc_pages_direct_compact.patch mm-page_alloc-move-set_page_refcounted-to-callers-of-__alloc_pages_direct_reclaim.patch mm-page_alloc-move-set_page_refcounted-to-callers-of-__alloc_pages_slowpath.patch mm-page_alloc-move-set_page_refcounted-to-end-of-__alloc_pages.patch mm-page_alloc-add-__alloc_frozen_pages.patch mm-mempolicy-add-alloc_frozen_pages.patch slab-allocate-frozen-pages.patch ocfs2-handle-a-symlink-read-error-correctly.patch ocfs2-convert-ocfs2_page_mkwrite-to-use-a-folio.patch ocfs2-pass-mmap_folio-around-instead-of-mmap_page.patch ocfs2-convert-ocfs2_read_inline_data-to-take-a-folio.patch ocfs2-use-a-folio-in-ocfs2_fast_symlink_read_folio.patch ocfs2-remove-ocfs2_start_walk_page_trans-prototype.patch

8 months, 2 weeks

1
0
0 0

+ mm-readahead-fix-large-folio-support-in-async-readahead.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/readahead: fix large folio support in async readahead has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-readahead-fix-large-folio-support-in-async-readahead.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Yafang Shao <laoar.shao(a)gmail.com> Subject: mm/readahead: fix large folio support in async readahead Date: Fri, 6 Dec 2024 16:30:25 +0800 When testing large folio support with XFS on our servers, we observed that only a few large folios are mapped when reading large files via mmap. After a thorough analysis, I identified it was caused by the `/sys/block/*/queue/read_ahead_kb` setting. On our test servers, this parameter is set to 128KB. After I tune it to 2MB, the large folio can work as expected. However, I believe the large folio behavior should not be dependent on the value of read_ahead_kb. It would be more robust if the kernel can automatically adopt to it. With /sys/block/*/queue/read_ahead_kb set to 128KB and performing a sequential read on a 1GB file using MADV_HUGEPAGE, the differences in /proc/meminfo are as follows: - before this patch FileHugePages: 18432 kB FilePmdMapped: 4096 kB - after this patch FileHugePages: 1067008 kB FilePmdMapped: 1048576 kB This shows that after applying the patch, the entire 1GB file is mapped to huge pages. The stable list is CCed, as without this patch, large folios don't function optimally in the readahead path. It's worth noting that if read_ahead_kb is set to a larger value that isn't aligned with huge page sizes (e.g., 4MB + 128KB), it may still fail to map to hugepages. Link: https://lkml.kernel.org/r/20241108141710.9721-1-laoar.shao@gmail.com Link: https://lkml.kernel.org/r/20241206083025.3478-1-laoar.shao@gmail.com Fixes: 4687fdbb805a ("mm/filemap: Support VM_HUGEPAGE for file mappings") Signed-off-by: Yafang Shao <laoar.shao(a)gmail.com> Tested-by: kernel test robot <oliver.sang(a)intel.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: David Hildenbrand <david(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/readahead.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/mm/readahead.c~mm-readahead-fix-large-folio-support-in-async-readahead +++ a/mm/readahead.c @@ -646,7 +646,11 @@ void page_cache_async_ra(struct readahea 1UL << order); if (index == expected) { ra->start += ra->size; - ra->size = get_next_ra_size(ra, max_pages); + /* + * In the case of MADV_HUGEPAGE, the actual size might exceed + * the readahead window. + */ + ra->size = max(ra->size, get_next_ra_size(ra, max_pages)); ra->async_size = ra->size; goto readit; } _ Patches currently in -mm which might be from laoar.shao(a)gmail.com are mm-readahead-fix-large-folio-support-in-async-readahead.patch

8 months, 2 weeks

1
0
0 0

[to-be-updated] mm-readahead-fix-large-folio-support-in-async-readahead.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/readahead: fix large folio support in async readahead has been removed from the -mm tree. Its filename was mm-readahead-fix-large-folio-support-in-async-readahead.patch This patch was dropped because an updated version will be issued ------------------------------------------------------ From: Yafang Shao <laoar.shao(a)gmail.com> Subject: mm/readahead: fix large folio support in async readahead Date: Fri, 8 Nov 2024 22:17:10 +0800 When testing large folio support with XFS on our servers, we observed that only a few large folios are mapped when reading large files via mmap. After a thorough analysis, I identified it was caused by the `/sys/block/*/queue/read_ahead_kb` setting. On our test servers, this parameter is set to 128KB. After I tune it to 2MB, the large folio can work as expected. However, I believe the large folio behavior should not be dependent on the value of read_ahead_kb. It would be more robust if the kernel can automatically adopt to it. With /sys/block/*/queue/read_ahead_kb set to 128KB and performing a sequential read on a 1GB file using MADV_HUGEPAGE, the differences in /proc/meminfo are as follows: - before this patch FileHugePages: 18432 kB FilePmdMapped: 4096 kB - after this patch FileHugePages: 1067008 kB FilePmdMapped: 1048576 kB This shows that after applying the patch, the entire 1GB file is mapped to huge pages. The stable list is CCed, as without this patch, large folios don't function optimally in the readahead path. It's worth noting that if read_ahead_kb is set to a larger value that isn't aligned with huge page sizes (e.g., 4MB + 128KB), it may still fail to map to hugepages. Link: https://lkml.kernel.org/r/20241108141710.9721-1-laoar.shao@gmail.com Fixes: 4687fdbb805a ("mm/filemap: Support VM_HUGEPAGE for file mappings") Suggested-by: Matthew Wilcox <willy(a)infradead.org> Signed-off-by: Yafang Shao <laoar.shao(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/readahead.c | 2 ++ 1 file changed, 2 insertions(+) --- a/mm/readahead.c~mm-readahead-fix-large-folio-support-in-async-readahead +++ a/mm/readahead.c @@ -390,6 +390,8 @@ static unsigned long get_next_ra_size(st return 4 * cur; if (cur <= max / 2) return 2 * cur; + if (cur > max) + return cur; return max; } _ Patches currently in -mm which might be from laoar.shao(a)gmail.com are mm-readahead-fix-large-folio-support-in-async-readahead-v3.patch

8 months, 2 weeks

1
0
0 0

[nacked] zram-panic-when-use-ext4-over-zram.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: zram: fix panic when using ext4 over zram has been removed from the -mm tree. Its filename was zram-panic-when-use-ext4-over-zram.patch This patch was dropped because it was nacked ------------------------------------------------------ From: caiqingfu <caiqingfu(a)ruijie.com.cn> Subject: zram: fix panic when using ext4 over zram Date: Fri, 29 Nov 2024 19:57:35 +0800 [ 52.073080 ] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 52.073511 ] Modules linked in: [ 52.074094 ] CPU: 0 UID: 0 PID: 3825 Comm: a.out Not tainted 6.12.0-07749-g28eb75e178d3-dirty #3 [ 52.074672 ] Hardware name: linux,dummy-virt (DT) [ 52.075128 ] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 52.075619 ] pc : obj_malloc+0x5c/0x160 [ 52.076402 ] lr : zs_malloc+0x200/0x570 [ 52.076630 ] sp : ffff80008dd335f0 [ 52.076797 ] x29: ffff80008dd335f0 x28: ffff000004104a00 x27: ffff000004dfc400 [ 52.077319 ] x26: 000000000000ca18 x25: ffff00003fcaf0e0 x24: ffff000006925cf0 [ 52.077785 ] x23: 0000000000000c0a x22: ffff0000032ee780 x21: ffff000006925cf0 [ 52.078257 ] x20: 0000000000088000 x19: 0000000000000000 x18: 0000000000fffc18 [ 52.078701 ] x17: 00000000fffffffd x16: 0000000000000803 x15: 00000000fffffffe [ 52.079203 ] x14: 000000001824429d x13: ffff000006e84000 x12: ffff000006e83fec [ 52.079711 ] x11: ffff000006e83000 x10: 00000000000002a5 x9 : ffff000006e83ff3 [ 52.080269 ] x8 : 0000000000000001 x7 : 0000000017e80000 x6 : 0000000000017e80 [ 52.080724 ] x5 : 0000000000000003 x4 : ffff00000402a5e8 x3 : 0000000000000066 [ 52.081081 ] x2 : ffff000006925cf0 x1 : ffff00000402a5e8 x0 : ffff000004104a00 [ 52.081595 ] Call trace: [ 52.081925 ] obj_malloc+0x5c/0x160 (P) [ 52.082220 ] zs_malloc+0x200/0x570 (L) [ 52.082504 ] zs_malloc+0x200/0x570 [ 52.082716 ] zram_submit_bio+0x788/0x9e8 [ 52.083017 ] __submit_bio+0x1c4/0x338 [ 52.083343 ] submit_bio_noacct_nocheck+0x128/0x2c0 [ 52.083518 ] submit_bio_noacct+0x1c8/0x308 [ 52.083722 ] submit_bio+0xa8/0x14c [ 52.083942 ] submit_bh_wbc+0x140/0x1bc [ 52.084088 ] __block_write_full_folio+0x23c/0x5f0 [ 52.084232 ] block_write_full_folio+0x134/0x21c [ 52.084524 ] write_cache_pages+0x64/0xd4 [ 52.084778 ] blkdev_writepages+0x50/0x8c [ 52.085040 ] do_writepages+0x80/0x2b0 [ 52.085292 ] filemap_fdatawrite_wbc+0x6c/0x90 [ 52.085597 ] __filemap_fdatawrite_range+0x64/0x94 [ 52.085900 ] filemap_fdatawrite+0x1c/0x28 [ 52.086158 ] sync_bdevs+0x170/0x17c [ 52.086374 ] ksys_sync+0x6c/0xb8 [ 52.086597 ] __arm64_sys_sync+0x10/0x20 [ 52.086847 ] invoke_syscall+0x44/0x100 [ 52.087230 ] el0_svc_common.constprop.0+0x40/0xe0 [ 52.087550 ] do_el0_svc+0x1c/0x28 [ 52.087690 ] el0_svc+0x30/0xd0 [ 52.087818 ] el0t_64_sync_handler+0xc8/0xcc [ 52.088046 ] el0t_64_sync+0x198/0x19c [ 52.088500 ] Code: 110004a5 6b0500df f9401273 54000160 (f9401664) [ 52.089097 ] ---[ end trace 0000000000000000 ]--- When using ext4 on zram, the following panic occasionally occurs under high memory usage The reason is that when the handle is obtained using the slow path, it will be re-compressed. If the data in the page changes, the compressed length may exceed the previous one. Overflow occurred when writing to zs_object, which then caused the panic. Comment the fast path and force the slow path. Adding a large number of read and write file systems can quickly reproduce it. The solution is to re-obtain the handle after re-compression if the length is different from the previous one. [senozhatsky(a)chromium.org: simplify zram_write_page() -ENOMEM return] Link: https://lkml.kernel.org/r/20241210093835.GN16709@google.com Link: https://lkml.kernel.org/r/20241129115735.136033-1-baicaiaichibaicai@gmail.c… Signed-off-by: caiqingfu <caiqingfu(a)ruijie.com.cn> Signed-off-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> Reviewed-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> Cc: Minchan Kim <minchan(a)kernel.org> Cc: <stable(a)vger.kernel.org> Cc: caiqingfu <caiqingfu(a)ruijie.com.cn> Cc: Minchan Kim <minchan(a)kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- drivers/block/zram/zram_drv.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/drivers/block/zram/zram_drv.c~zram-panic-when-use-ext4-over-zram +++ a/drivers/block/zram/zram_drv.c @@ -1633,6 +1633,7 @@ static int zram_write_page(struct zram * unsigned long alloced_pages; unsigned long handle = -ENOMEM; unsigned int comp_len = 0; + unsigned int last_comp_len = 0; void *src, *dst, *mem; struct zcomp_strm *zstrm; unsigned long element = 0; @@ -1664,6 +1665,11 @@ compress_again: if (comp_len >= huge_class_size) comp_len = PAGE_SIZE; + + if (last_comp_len && (last_comp_len != comp_len)) { + zs_free(zram->mem_pool, handle); + handle = -ENOMEM; + } /* * handle allocation has 2 paths: * a) fast path is executed with preemption disabled (for @@ -1692,8 +1698,10 @@ compress_again: if (IS_ERR_VALUE(handle)) return PTR_ERR((void *)handle); - if (comp_len != PAGE_SIZE) + if (comp_len != PAGE_SIZE) { + last_comp_len = comp_len; goto compress_again; + } /* * If the page is not compressible, you need to acquire the * lock and execute the code below. The zcomp_stream_get() _ Patches currently in -mm which might be from caiqingfu(a)ruijie.com.cn are

8 months, 2 weeks

1
0
0 0

+ mm-compaction-dont-use-alloc_cma-in-long-term-gup-flow.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm, compaction: don't use ALLOC_CMA in long term GUP flow has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-compaction-dont-use-alloc_cma-in-long-term-gup-flow.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: yangge <yangge1116(a)126.com> Subject: mm, compaction: don't use ALLOC_CMA in long term GUP flow Date: Sun, 15 Dec 2024 18:01:07 +0800 Since commit 984fdba6a32e ("mm, compaction: use proper alloc_flags in __compaction_suitable()") allow compaction to proceed when free pages required for compaction reside in the CMA pageblocks, it's possible that __compaction_suitable() always returns true, and in some cases, it's not acceptable. There are 4 NUMA nodes on my machine, and each NUMA node has 32GB of memory. I have configured 16GB of CMA memory on each NUMA node, and starting a 32GB virtual machine with device passthrough is extremely slow, taking almost an hour. During the start-up of the virtual machine, it will call pin_user_pages_remote(..., FOLL_LONGTERM, ...) to allocate memory. Long term GUP cannot allocate memory from CMA area, so a maximum of 16 GB of no-CMA memory on a NUMA node can be used as virtual machine memory. Since there is 16G of free CMA memory on the NUMA node, watermark for order-0 always be met for compaction, so __compaction_suitable() always returns true, even if the node is unable to allocate non-CMA memory for the virtual machine. For costly allocations, because __compaction_suitable() always returns true, __alloc_pages_slowpath() can't exit at the appropriate place, resulting in excessively long virtual machine startup times. Call trace: __alloc_pages_slowpath if (compact_result == COMPACT_SKIPPED || compact_result == COMPACT_DEFERRED) goto nopage; // should exit __alloc_pages_slowpath() from here In order to quickly fall back to remote node, we should remove ALLOC_CMA both in __compaction_suitable() and __isolate_free_page() in long term GUP flow. After this fix, starting a 32GB virtual machine with device passthrough takes only a few seconds. Link: https://lkml.kernel.org/r/1734256867-19614-1-git-send-email-yangge1116@126.… Fixes: 984fdba6a32e ("mm, compaction: use proper alloc_flags in __compaction_suitable()") Signed-off-by: yangge <yangge1116(a)126.com> Cc: Baolin Wang <baolin.wang(a)linux.alibaba.com> Cc: David Hildenbrand <david(a)redhat.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/compaction.h | 6 ++++-- mm/compaction.c | 18 +++++++++++------- mm/page_alloc.c | 4 +++- mm/vmscan.c | 4 ++-- 4 files changed, 20 insertions(+), 12 deletions(-) --- a/include/linux/compaction.h~mm-compaction-dont-use-alloc_cma-in-long-term-gup-flow +++ a/include/linux/compaction.h @@ -90,7 +90,8 @@ extern enum compact_result try_to_compac struct page **page); extern void reset_isolation_suitable(pg_data_t *pgdat); extern bool compaction_suitable(struct zone *zone, int order, - int highest_zoneidx); + int highest_zoneidx, + unsigned int alloc_flags); extern void compaction_defer_reset(struct zone *zone, int order, bool alloc_success); @@ -108,7 +109,8 @@ static inline void reset_isolation_suita } static inline bool compaction_suitable(struct zone *zone, int order, - int highest_zoneidx) + int highest_zoneidx, + unsigned int alloc_flags) { return false; } --- a/mm/compaction.c~mm-compaction-dont-use-alloc_cma-in-long-term-gup-flow +++ a/mm/compaction.c @@ -2379,9 +2379,11 @@ static enum compact_result compact_finis static bool __compaction_suitable(struct zone *zone, int order, int highest_zoneidx, + unsigned int alloc_flags, unsigned long wmark_target) { unsigned long watermark; + bool use_cma; /* * Watermarks for order-0 must be met for compaction to be able to * isolate free pages for migration targets. This means that the @@ -2393,25 +2395,27 @@ static bool __compaction_suitable(struct * even if compaction succeeds. * For costly orders, we require low watermark instead of min for * compaction to proceed to increase its chances. - * ALLOC_CMA is used, as pages in CMA pageblocks are considered - * suitable migration targets + * In addition to long term GUP flow, ALLOC_CMA is used, as pages in + * CMA pageblocks are considered suitable migration targets */ watermark = (order > PAGE_ALLOC_COSTLY_ORDER) ? low_wmark_pages(zone) : min_wmark_pages(zone); watermark += compact_gap(order); + use_cma = !!(alloc_flags & ALLOC_CMA); return __zone_watermark_ok(zone, 0, watermark, highest_zoneidx, - ALLOC_CMA, wmark_target); + use_cma ? ALLOC_CMA : 0, wmark_target); } /* * compaction_suitable: Is this suitable to run compaction on this zone now? */ -bool compaction_suitable(struct zone *zone, int order, int highest_zoneidx) +bool compaction_suitable(struct zone *zone, int order, int highest_zoneidx, + unsigned int alloc_flags) { enum compact_result compact_result; bool suitable; - suitable = __compaction_suitable(zone, order, highest_zoneidx, + suitable = __compaction_suitable(zone, order, highest_zoneidx, alloc_flags, zone_page_state(zone, NR_FREE_PAGES)); /* * fragmentation index determines if allocation failures are due to @@ -2472,7 +2476,7 @@ bool compaction_zonelist_suitable(struct available = zone_reclaimable_pages(zone) / order; available += zone_page_state_snapshot(zone, NR_FREE_PAGES); if (__compaction_suitable(zone, order, ac->highest_zoneidx, - available)) + alloc_flags, available)) return true; } @@ -2497,7 +2501,7 @@ compaction_suit_allocation_order(struct alloc_flags)) return COMPACT_SUCCESS; - if (!compaction_suitable(zone, order, highest_zoneidx)) + if (!compaction_suitable(zone, order, highest_zoneidx, alloc_flags)) return COMPACT_SKIPPED; return COMPACT_CONTINUE; --- a/mm/page_alloc.c~mm-compaction-dont-use-alloc_cma-in-long-term-gup-flow +++ a/mm/page_alloc.c @@ -2812,6 +2812,7 @@ int __isolate_free_page(struct page *pag { struct zone *zone = page_zone(page); int mt = get_pageblock_migratetype(page); + bool pin; if (!is_migrate_isolate(mt)) { unsigned long watermark; @@ -2822,7 +2823,8 @@ int __isolate_free_page(struct page *pag * exists. */ watermark = zone->_watermark[WMARK_MIN] + (1UL << order); - if (!zone_watermark_ok(zone, 0, watermark, 0, ALLOC_CMA)) + pin = !!(current->flags & PF_MEMALLOC_PIN); + if (!zone_watermark_ok(zone, 0, watermark, 0, pin ? 0 : ALLOC_CMA)) return 0; } --- a/mm/vmscan.c~mm-compaction-dont-use-alloc_cma-in-long-term-gup-flow +++ a/mm/vmscan.c @@ -5861,7 +5861,7 @@ static inline bool should_continue_recla sc->reclaim_idx, 0)) return false; - if (compaction_suitable(zone, sc->order, sc->reclaim_idx)) + if (compaction_suitable(zone, sc->order, sc->reclaim_idx, ALLOC_CMA)) return false; } @@ -6089,7 +6089,7 @@ static inline bool compaction_ready(stru return true; /* Compaction cannot yet proceed. Do reclaim. */ - if (!compaction_suitable(zone, sc->order, sc->reclaim_idx)) + if (!compaction_suitable(zone, sc->order, sc->reclaim_idx, ALLOC_CMA)) return false; /* _ Patches currently in -mm which might be from yangge1116(a)126.com are mm-compaction-dont-use-alloc_cma-in-long-term-gup-flow.patch

8 months, 2 weeks

1
0
0 0

[PATCH v2] selinux: ignore unknown extended permissions

by Thiébaud Weksteen

When evaluating extended permissions, ignore unknown permissions instead of calling BUG(). This commit ensures that future permissions can be added without interfering with older kernels. Fixes: fa1aa143ac4a ("selinux: extended permissions for ioctls") Cc: stable(a)vger.kernel.org Signed-off-by: Thiébaud Weksteen <tweek(a)google.com> --- v2: Add pr_warn_once, remove other BUG() call for key.specified security/selinux/ss/services.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c index 971c45d576ba..3d5c563cfc4c 100644 --- a/security/selinux/ss/services.c +++ b/security/selinux/ss/services.c @@ -979,7 +979,10 @@ void services_compute_xperms_decision(struct extended_perms_decision *xpermd, return; break; default: - BUG(); + pr_warn_once( + "SELinux: unknown extended permission (%u) will be ignored\n", + node->datum.u.xperms->specified); + return; } if (node->key.specified == AVTAB_XPERMS_ALLOWED) { @@ -998,7 +1001,8 @@ void services_compute_xperms_decision(struct extended_perms_decision *xpermd, &node->datum.u.xperms->perms, xpermd->dontaudit); } else { - BUG(); + pr_warn_once("SELinux: unknown specified key (%u)\n", + node->key.specified); } } -- 2.47.0.338.g60cca15819-goog

8 months, 2 weeks

2
1
0 0

[PATCH v2 0/7] of: fix bugs and improve codes

by Zijun Hu

This patch series is to fix bugs and improve codes for drivers/of/*. Signed-off-by: Zijun Hu <quic_zijuhu(a)quicinc.com> --- Changes in v2: - Drop applied/conflict/TBD patches. - Correct based on Rob's comments. - Link to v1: https://lore.kernel.org/r/20241206-of_core_fix-v1-0-dc28ed56bec3@quicinc.com --- Zijun Hu (7): of: Fix API of_find_node_opts_by_path() finding OF device node failure of: unittest: Add a test case for API of_find_node_opts_by_path() of: Correct child specifier used as input of the 2nd nexus node of: Exchange implementation between of_property_present() and of_property_read_bool() of: Fix available buffer size calculating error in API of_device_uevent_modalias() of: Fix potential wrong MODALIAS uevent value of: Do not expose of_alias_scan() and correct its comments drivers/of/base.c | 13 +++--- drivers/of/device.c | 33 +++++++--------- drivers/of/module.c | 103 +++++++++++++++++++++++++++++------------------- drivers/of/of_private.h | 2 + drivers/of/pdt.c | 2 + drivers/of/unittest.c | 9 +++++ include/linux/of.h | 29 +++++++------- 7 files changed, 109 insertions(+), 82 deletions(-) --- base-commit: 0f7ca6f69354e0c3923bbc28c92d0ecab4d50a3e change-id: 20241206-of_core_fix-dc3021a06418 Best regards, -- Zijun Hu <quic_zijuhu(a)quicinc.com>

8 months, 2 weeks

1
2
0 0

[PATCH 6.1.y 1/2] exfat: support dynamic allocate bh for exfat_entry_set_cache

by Harshit Mogalapalli

From: Yuezhang Mo <Yuezhang.Mo(a)sony.com> [ Upstream commit a3ff29a95fde16906304455aa8c0bd84eb770258 ] In special cases, a file or a directory may occupied more than 19 directory entries, pre-allocating 3 bh is not enough. Such as - Support vendor secondary directory entry in the future. - Since file directory entry is damaged, the SecondaryCount field is bigger than 18. So this commit supports dynamic allocation of bh. Signed-off-by: Yuezhang Mo <Yuezhang.Mo(a)sony.com> Reviewed-by: Andy Wu <Andy.Wu(a)sony.com> Reviewed-by: Aoyama Wataru <wataru.aoyama(a)sony.com> Reviewed-by: Sungjong Seo <sj1557.seo(a)samsung.com> Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> (cherry picked from commit a3ff29a95fde16906304455aa8c0bd84eb770258) [Harshit: Backport - clean cherry-pick to 6.1.y] Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli(a)oracle.com> --- This is already in 5.10.y and 5.15.y, let us apply this to 6.1.y, this also has a fix commit: 89fc548767a2 ("exfat: fix potential deadlock on __exfat_get_dentry_set"). Both apply cleanly on 6.1.y and builds fine. No exfat specific testing is done. --- fs/exfat/dir.c | 15 +++++++++++++++ fs/exfat/exfat_fs.h | 5 ++++- 2 files changed, 19 insertions(+), 1 deletion(-) diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c index 51b03b0dd5f7..6fd9a06cc7d0 100644 --- a/fs/exfat/dir.c +++ b/fs/exfat/dir.c @@ -613,6 +613,10 @@ int exfat_free_dentry_set(struct exfat_entry_set_cache *es, int sync) bforget(es->bh[i]); else brelse(es->bh[i]); + + if (IS_DYNAMIC_ES(es)) + kfree(es->bh); + kfree(es); return err; } @@ -845,6 +849,7 @@ struct exfat_entry_set_cache *exfat_get_dentry_set(struct super_block *sb, /* byte offset in sector */ off = EXFAT_BLK_OFFSET(byte_offset, sb); es->start_off = off; + es->bh = es->__bh; /* sector offset in cluster */ sec = EXFAT_B_TO_BLK(byte_offset, sb); @@ -864,6 +869,16 @@ struct exfat_entry_set_cache *exfat_get_dentry_set(struct super_block *sb, es->num_entries = num_entries; num_bh = EXFAT_B_TO_BLK_ROUND_UP(off + num_entries * DENTRY_SIZE, sb); + if (num_bh > ARRAY_SIZE(es->__bh)) { + es->bh = kmalloc_array(num_bh, sizeof(*es->bh), GFP_KERNEL); + if (!es->bh) { + brelse(bh); + kfree(es); + return NULL; + } + es->bh[0] = bh; + } + for (i = 1; i < num_bh; i++) { /* get the next sector */ if (exfat_is_last_sector_in_cluster(sbi, sec)) { diff --git a/fs/exfat/exfat_fs.h b/fs/exfat/exfat_fs.h index e0af6ace633c..c79c78bf265b 100644 --- a/fs/exfat/exfat_fs.h +++ b/fs/exfat/exfat_fs.h @@ -169,10 +169,13 @@ struct exfat_entry_set_cache { bool modified; unsigned int start_off; int num_bh; - struct buffer_head *bh[DIR_CACHE_SIZE]; + struct buffer_head *__bh[DIR_CACHE_SIZE]; + struct buffer_head **bh; unsigned int num_entries; }; +#define IS_DYNAMIC_ES(es) ((es)->__bh != (es)->bh) + struct exfat_dir_entry { struct exfat_chain dir; int entry; -- 2.46.0

8 months, 2 weeks

2
3
0 0

FAILED: patch "[PATCH] rust: kbuild: set `bindgen`'s Rust target version" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x 7a5f93ea5862da91488975acaa0c7abd508f192b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024121500-switch-jab-65fc@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7a5f93ea5862da91488975acaa0c7abd508f192b Mon Sep 17 00:00:00 2001 From: Miguel Ojeda <ojeda(a)kernel.org> Date: Sat, 23 Nov 2024 19:03:23 +0100 Subject: [PATCH] rust: kbuild: set `bindgen`'s Rust target version MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Each `bindgen` release may upgrade the list of Rust targets. For instance, currently, in their master branch [1], the latest ones are: Nightly => { vectorcall_abi: #124485, ptr_metadata: #81513, layout_for_ptr: #69835, }, Stable_1_77(77) => { offset_of: #106655 }, Stable_1_73(73) => { thiscall_abi: #42202 }, Stable_1_71(71) => { c_unwind_abi: #106075 }, Stable_1_68(68) => { abi_efiapi: #105795 }, By default, the highest stable release in their list is used, and users are expected to set one if they need to support older Rust versions (e.g. see [2]). Thus, over time, new Rust features are used by default, and at some point, it is likely that `bindgen` will emit Rust code that requires a Rust version higher than our minimum (or perhaps enabling an unstable feature). Currently, there is no problem because the maximum they have, as seen above, is Rust 1.77.0, and our current minimum is Rust 1.78.0. Therefore, set a Rust target explicitly now to prevent going forward in time too much and thus getting potential build failures at some point. Since we also support a minimum `bindgen` version, and since `bindgen` does not support passing unknown Rust target versions, we need to use the list of our minimum `bindgen` version, rather than the latest. So, since `bindgen` 0.65.1 had this list [3], we need to use Rust 1.68.0: /// Rust stable 1.64 /// * `core_ffi_c` ([Tracking issue](https://github.com/rust-lang/rust/issues/94501)) => Stable_1_64 => 1.64; /// Rust stable 1.68 /// * `abi_efiapi` calling convention ([Tracking issue](https://github.com/rust-lang/rust/issues/65815)) => Stable_1_68 => 1.68; /// Nightly rust /// * `thiscall` calling convention ([Tracking issue](https://github.com/rust-lang/rust/issues/42202)) /// * `vectorcall` calling convention (no tracking issue) /// * `c_unwind` calling convention ([Tracking issue](https://github.com/rust-lang/rust/issues/74990)) => Nightly => nightly; ... /// Latest stable release of Rust pub const LATEST_STABLE_RUST: RustTarget = RustTarget::Stable_1_68; Thus add the `--rust-target 1.68` parameter. Add a comment as well explaining this. An alternative would be to use the currently running (i.e. actual) `rustc` and `bindgen` versions to pick a "better" Rust target version. However, that would introduce more moving parts depending on the user setup and is also more complex to implement. Starting with `bindgen` 0.71.0 [4], we will be able to set any future Rust version instead, i.e. we will be able to set here our minimum supported Rust version. Christian implemented it [5] after seeing this patch. Thanks! Cc: Christian Poveda <git(a)pvdrz.com> Cc: Emilio Cobos Álvarez <emilio(a)crisal.io> Cc: stable(a)vger.kernel.org # needed for 6.12.y; unneeded for 6.6.y; do not apply to 6.1.y Fixes: c844fa64a2d4 ("rust: start supporting several `bindgen` versions") Link: https://github.com/rust-lang/rust-bindgen/blob/21c60f473f4e824d4aa9b2b50805… [1] Link: https://github.com/rust-lang/rust-bindgen/issues/2960 [2] Link: https://github.com/rust-lang/rust-bindgen/blob/7d243056d335fdc4537f7bca73c0… [3] Link: https://github.com/rust-lang/rust-bindgen/blob/main/CHANGELOG.md#0710-2024-… [4] Link: https://github.com/rust-lang/rust-bindgen/pull/2993 [5] Reviewed-by: Alice Ryhl <aliceryhl(a)google.com> Link: https://lore.kernel.org/r/20241123180323.255997-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda(a)kernel.org> diff --git a/rust/Makefile b/rust/Makefile index 9da9042fd627..a40a3936126d 100644 --- a/rust/Makefile +++ b/rust/Makefile @@ -280,9 +280,22 @@ endif # architecture instead of generating `usize`. bindgen_c_flags_final = $(bindgen_c_flags_lto) -fno-builtin -D__BINDGEN__ +# Each `bindgen` release may upgrade the list of Rust target versions. By +# default, the highest stable release in their list is used. Thus we need to set +# a `--rust-target` to avoid future `bindgen` releases emitting code that +# `rustc` may not understand. On top of that, `bindgen` does not support passing +# an unknown Rust target version. +# +# Therefore, the Rust target for `bindgen` can be only as high as the minimum +# Rust version the kernel supports and only as high as the greatest stable Rust +# target supported by the minimum `bindgen` version the kernel supports (that +# is, if we do not test the actual `rustc`/`bindgen` versions running). +# +# Starting with `bindgen` 0.71.0, we will be able to set any future Rust version +# instead, i.e. we will be able to set here our minimum supported Rust version. quiet_cmd_bindgen = BINDGEN $@ cmd_bindgen = \ - $(BINDGEN) $< $(bindgen_target_flags) \ + $(BINDGEN) $< $(bindgen_target_flags) --rust-target 1.68 \ --use-core --with-derive-default --ctypes-prefix ffi --no-layout-tests \ --no-debug '.*' --enable-function-attribute-detection \ -o $@ -- $(bindgen_c_flags_final) -DMODULE \

8 months, 2 weeks

3
2
0 0

[PATCH] fbdev/udlfb: Remove world-writability from EDID attribute

by Thomas Weißschuh

It should not be possible for every user to override the EDID. Limit it to the system administrator. Fixes: 8ef8cc4fca4a ("staging: udlfb: support for writing backup EDID to sysfs file") Cc: stable(a)vger.kernel.org Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net> --- The EDID passed through sysfs is only used as a fallback if the hardware does not provide one. To me it still feels incorrect to have this world-writable. --- drivers/video/fbdev/udlfb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c index 71ac9e36f67c68aa7a54dce32323047a2a9a48bf..391bdb71197549caa839d862f0ce7456dc7bf9ec 100644 --- a/drivers/video/fbdev/udlfb.c +++ b/drivers/video/fbdev/udlfb.c @@ -1480,7 +1480,7 @@ static ssize_t metrics_reset_store(struct device *fbdev, static const struct bin_attribute edid_attr = { .attr.name = "edid", - .attr.mode = 0666, + .attr.mode = 0644, .size = EDID_LENGTH, .read = edid_show, .write = edid_store --- base-commit: 2d8308bf5b67dff50262d8a9260a50113b3628c6 change-id: 20241215-udlfb-perms-bb6ed270facf Best regards, -- Thomas Weißschuh <linux(a)weissschuh.net>

8 months, 2 weeks

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2024