October 2025 - Linux-stable-mirror

[PATCH v4 resend 1/7] efi: Add missing static initializer for efi_mm::cpus_allowed_lock

by Ard Biesheuvel

From: Ard Biesheuvel <ardb(a)kernel.org> Initialize the cpus_allowed_lock struct member of efi_mm. Cc: <stable(a)vger.kernel.org> Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> --- drivers/firmware/efi/efi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c index 1ce428e2ac8a..fc407d891348 100644 --- a/drivers/firmware/efi/efi.c +++ b/drivers/firmware/efi/efi.c @@ -74,6 +74,9 @@ struct mm_struct efi_mm = { .page_table_lock = __SPIN_LOCK_UNLOCKED(efi_mm.page_table_lock), .mmlist = LIST_HEAD_INIT(efi_mm.mmlist), .cpu_bitmap = { [BITS_TO_LONGS(NR_CPUS)] = 0}, +#ifdef CONFIG_SCHED_MM_CID + .cpus_allowed_lock = __RAW_SPIN_LOCK_UNLOCKED(efi_mm.cpus_allowed_lock), +#endif }; struct workqueue_struct *efi_rts_wq; -- 2.51.0.869.ge66316f041-goog

2 weeks, 6 days

1
0
0 0

El feedback efectivo empieza con datos claros

by Daniel Rodríguez

Fortalece la evaluación del desempeño Fortalece la evaluación del desempeño con Vorecol 360 Feedback. Hola, , La retroalimentación es una de las herramientas más poderosas para el desarrollo de las personas, pero muchas veces se limita a la opinión de un solo líder. Con una visión más amplia, las decisiones se vuelven más justas y efectivas. Vorecol 360 Feedback te permite evaluar el desempeño desde múltiples perspectivas, obteniendo una imagen completa y objetiva. Con Vorecol 360 Feedback puedes: • Recibir evaluaciones desde diferentes fuentes: líderes, pares, colaboradores y autoevaluación. • Personalizar competencias y criterios según el rol y las metas de la organización. • Generar reportes claros y accionables, con áreas de mejora y fortalezas destacadas. Esto ayuda a crear una cultura de retroalimentación continua y mejora constante en todos los niveles. Si estás buscando fortalecer la evaluación del desempeño, esta puede ser una muy buena opción. Si quieres conocer más puedes responder este correo o simplemente contactarme, mis datos están abajo o da clic aquí Saludos, -------------- Atte.: Daniel Rodríguez Ciudad de México: (55) 5018 0565 WhatsApp: +52 33 1607 2089 Si no deseas recibir más correos, haz clic aquí para darte de baja. Para remover su dirección de esta lista haga <a href="https://s1.arrobamail.com/unsuscribe.php?id=yiwtsrewispouseup">click aquí</a>

2 weeks, 6 days

1
0
0 0

[merged mm-hotfixes-stable] mm-prevent-poison-consumption-when-splitting-thp.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm: prevent poison consumption when splitting THP has been removed from the -mm tree. Its filename was mm-prevent-poison-consumption-when-splitting-thp.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: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com> Subject: mm: prevent poison consumption when splitting THP Date: Sat, 11 Oct 2025 15:55:19 +0800 When performing memory error injection on a THP (Transparent Huge Page) mapped to userspace on an x86 server, the kernel panics with the following trace. The expected behavior is to terminate the affected process instead of panicking the kernel, as the x86 Machine Check code can recover from an in-userspace #MC. mce: [Hardware Error]: CPU 0: Machine Check Exception: f Bank 3: bd80000000070134 mce: [Hardware Error]: RIP 10:<ffffffff8372f8bc> {memchr_inv+0x4c/0xf0} mce: [Hardware Error]: TSC afff7bbff88a ADDR 1d301b000 MISC 80 PPIN 1e741e77539027db mce: [Hardware Error]: PROCESSOR 0:d06d0 TIME 1758093249 SOCKET 0 APIC 0 microcode 80000320 mce: [Hardware Error]: Run the above through 'mcelog --ascii' mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel Kernel panic - not syncing: Fatal local machine check The root cause of this panic is that handling a memory failure triggered by an in-userspace #MC necessitates splitting the THP. The splitting process employs a mechanism, implemented in try_to_map_unused_to_zeropage(), which reads the pages in the THP to identify zero-filled pages. However, reading the pages in the THP results in a second in-kernel #MC, occurring before the initial memory_failure() completes, ultimately leading to a kernel panic. See the kernel panic call trace on the two #MCs. First Machine Check occurs // [1] memory_failure() // [2] try_to_split_thp_page() split_huge_page() split_huge_page_to_list_to_order() __folio_split() // [3] remap_page() remove_migration_ptes() remove_migration_pte() try_to_map_unused_to_zeropage() // [4] memchr_inv() // [5] Second Machine Check occurs // [6] Kernel panic [1] Triggered by accessing a hardware-poisoned THP in userspace, which is typically recoverable by terminating the affected process. [2] Call folio_set_has_hwpoisoned() before try_to_split_thp_page(). [3] Pass the RMP_USE_SHARED_ZEROPAGE remap flag to remap_page(). [4] Try to map the unused THP to zeropage. [5] Re-access pages in the hw-poisoned THP in the kernel. [6] Triggered in-kernel, leading to a panic kernel. In Step[2], memory_failure() sets the poisoned flag on the page in the THP by TestSetPageHWPoison() before calling try_to_split_thp_page(). As suggested by David Hildenbrand, fix this panic by not accessing to the poisoned page in the THP during zeropage identification, while continuing to scan unaffected pages in the THP for possible zeropage mapping. This prevents a second in-kernel #MC that would cause kernel panic in Step[4]. Thanks to Andrew Zaborowski for his initial work on fixing this issue. Link: https://lkml.kernel.org/r/20251015064926.1887643-1-qiuxu.zhuo@intel.com Link: https://lkml.kernel.org/r/20251011075520.320862-1-qiuxu.zhuo@intel.com Fixes: b1f202060afe ("mm: remap unused subpages to shared zeropage when splitting isolated thp") Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com> Reported-by: Farrah Chen <farrah.chen(a)intel.com> Suggested-by: David Hildenbrand <david(a)redhat.com> Acked-by: David Hildenbrand <david(a)redhat.com> Tested-by: Farrah Chen <farrah.chen(a)intel.com> Tested-by: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com> Acked-by: Lance Yang <lance.yang(a)linux.dev> Reviewed-by: Wei Yang <richard.weiyang(a)gmail.com> Acked-by: Zi Yan <ziy(a)nvidia.com> Reviewed-by: Miaohe Lin <linmiaohe(a)huawei.com> Cc: Barry Song <baohua(a)kernel.org> Cc: Dev Jain <dev.jain(a)arm.com> Cc: Jiaqi Yan <jiaqiyan(a)google.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: "Luck, Tony" <tony.luck(a)intel.com> Cc: Mariano Pache <npache(a)redhat.com> Cc: Miaohe Lin <linmiaohe(a)huawei.com> Cc: Naoya Horiguchi <nao.horiguchi(a)gmail.com> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/huge_memory.c | 3 +++ mm/migrate.c | 3 ++- 2 files changed, 5 insertions(+), 1 deletion(-) --- a/mm/huge_memory.c~mm-prevent-poison-consumption-when-splitting-thp +++ a/mm/huge_memory.c @@ -4109,6 +4109,9 @@ static bool thp_underused(struct folio * if (khugepaged_max_ptes_none == HPAGE_PMD_NR - 1) return false; + if (folio_contain_hwpoisoned_page(folio)) + return false; + for (i = 0; i < folio_nr_pages(folio); i++) { if (pages_identical(folio_page(folio, i), ZERO_PAGE(0))) { if (++num_zero_pages > khugepaged_max_ptes_none) --- a/mm/migrate.c~mm-prevent-poison-consumption-when-splitting-thp +++ a/mm/migrate.c @@ -301,8 +301,9 @@ static bool try_to_map_unused_to_zeropag struct page *page = folio_page(folio, idx); pte_t newpte; - if (PageCompound(page)) + if (PageCompound(page) || PageHWPoison(page)) return false; + VM_BUG_ON_PAGE(!PageAnon(page), page); VM_BUG_ON_PAGE(!PageLocked(page), page); VM_BUG_ON_PAGE(pte_present(old_pte), page); _ Patches currently in -mm which might be from qiuxu.zhuo(a)intel.com are

2 weeks, 6 days

1
0
0 0

[merged mm-hotfixes-stable] ocfs2-clear-extent-cache-after-moving-defragmenting-extents.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: ocfs2: clear extent cache after moving/defragmenting extents has been removed from the -mm tree. Its filename was ocfs2-clear-extent-cache-after-moving-defragmenting-extents.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: Deepanshu Kartikey <kartikey406(a)gmail.com> Subject: ocfs2: clear extent cache after moving/defragmenting extents Date: Thu, 9 Oct 2025 21:19:03 +0530 The extent map cache can become stale when extents are moved or defragmented, causing subsequent operations to see outdated extent flags. This triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters(). The problem occurs when: 1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED 2. ioctl(FITRIM) triggers ocfs2_move_extents() 3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2) 4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent() which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0) 5. The extent map cache is not invalidated after the move 6. Later write() operations read stale cached flags (0x2) but disk has updated flags (0x0), causing a mismatch 7. BUG_ON(!(rec->e_flags & OCFS2_EXT_REFCOUNTED)) triggers Fix by clearing the extent map cache after each extent move/defrag operation in __ocfs2_move_extents_range(). This ensures subsequent operations read fresh extent data from disk. Link: https://lore.kernel.org/all/20251009142917.517229-1-kartikey406@gmail.com/T/ Link: https://lkml.kernel.org/r/20251009154903.522339-1-kartikey406@gmail.com Fixes: 53069d4e7695 ("Ocfs2/move_extents: move/defrag extents within a certain range.") Signed-off-by: Deepanshu Kartikey <kartikey406(a)gmail.com> Reported-by: syzbot+6fdd8fa3380730a4b22c(a)syzkaller.appspotmail.com Tested-by: syzbot+6fdd8fa3380730a4b22c(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?id=2959889e1f6e216585ce522f7e8bc002b46ad9… Reviewed-by: Mark Fasheh <mark(a)fasheh.com> Reviewed-by: Joseph Qi <joseph.qi(a)linux.alibaba.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: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/ocfs2/move_extents.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/fs/ocfs2/move_extents.c~ocfs2-clear-extent-cache-after-moving-defragmenting-extents +++ a/fs/ocfs2/move_extents.c @@ -867,6 +867,11 @@ static int __ocfs2_move_extents_range(st mlog_errno(ret); goto out; } + /* + * Invalidate extent cache after moving/defragging to prevent + * stale cached data with outdated extent flags. + */ + ocfs2_extent_map_trunc(inode, cpos); context->clusters_moved += alloc_size; next: _ Patches currently in -mm which might be from kartikey406(a)gmail.com are hugetlbfs-move-lock-assertions-after-early-returns-in-huge_pmd_unshare.patch

2 weeks, 6 days

1
0
0 0

[merged mm-hotfixes-stable] mm-dont-spin-in-add_stack_record-when-gfp-flags-dont-allow.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm: don't spin in add_stack_record when gfp flags don't allow has been removed from the -mm tree. Its filename was mm-dont-spin-in-add_stack_record-when-gfp-flags-dont-allow.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: Alexei Starovoitov <ast(a)kernel.org> Subject: mm: don't spin in add_stack_record when gfp flags don't allow Date: Thu, 9 Oct 2025 17:15:13 -0700 syzbot was able to find the following path: add_stack_record_to_list mm/page_owner.c:182 [inline] inc_stack_record_count mm/page_owner.c:214 [inline] __set_page_owner+0x2c3/0x4a0 mm/page_owner.c:333 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851 prep_new_page mm/page_alloc.c:1859 [inline] get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858 alloc_pages_nolock_noprof+0x94/0x120 mm/page_alloc.c:7554 Don't spin in add_stack_record_to_list() when it is called from *_nolock() context. Link: https://lkml.kernel.org/r/CAADnVQK_8bNYEA7TJYgwTYR57=TTFagsvRxp62pFzS_z129e… Fixes: 97769a53f117 ("mm, bpf: Introduce try_alloc_pages() for opportunistic page allocation") Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Reported-by: syzbot+8259e1d0e3ae8ed0c490(a)syzkaller.appspotmail.com Reported-by: syzbot+665739f456b28f32b23d(a)syzkaller.appspotmail.com Acked-by: Vlastimil Babka <vbabka(a)suse.cz> Reviewed-by: Oscar Salvador <osalvador(a)suse.de> Cc: Brendan Jackman <jackmanb(a)google.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Zi Yan <ziy(a)nvidia.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_owner.c | 3 +++ 1 file changed, 3 insertions(+) --- a/mm/page_owner.c~mm-dont-spin-in-add_stack_record-when-gfp-flags-dont-allow +++ a/mm/page_owner.c @@ -168,6 +168,9 @@ static void add_stack_record_to_list(str unsigned long flags; struct stack *stack; + if (!gfpflags_allow_spinning(gfp_mask)) + return; + set_current_in_page_owner(); stack = kmalloc(sizeof(*stack), gfp_nested_mask(gfp_mask)); if (!stack) { _ Patches currently in -mm which might be from ast(a)kernel.org are

2 weeks, 6 days

1
0
0 0

[merged mm-hotfixes-stable] dma-debug-dont-report-false-positives-with-dma_bounce_unaligned_kmalloc.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: dma-debug: don't report false positives with DMA_BOUNCE_UNALIGNED_KMALLOC has been removed from the -mm tree. Its filename was dma-debug-dont-report-false-positives-with-dma_bounce_unaligned_kmalloc.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: Marek Szyprowski <m.szyprowski(a)samsung.com> Subject: dma-debug: don't report false positives with DMA_BOUNCE_UNALIGNED_KMALLOC Date: Thu, 9 Oct 2025 16:15:08 +0200 Commit 370645f41e6e ("dma-mapping: force bouncing if the kmalloc() size is not cache-line-aligned") introduced DMA_BOUNCE_UNALIGNED_KMALLOC feature and permitted architecture specific code configure kmalloc slabs with sizes smaller than the value of dma_get_cache_alignment(). When that feature is enabled, the physical address of some small kmalloc()-ed buffers might be not aligned to the CPU cachelines, thus not really suitable for typical DMA. To properly handle that case a SWIOTLB buffer bouncing is used, so no CPU cache corruption occurs. When that happens, there is no point reporting a false-positive DMA-API warning that the buffer is not properly aligned, as this is not a client driver fault. [m.szyprowski(a)samsung.com: replace is_swiotlb_allocated() with is_swiotlb_active(), per Catalin] Link: https://lkml.kernel.org/r/20251010173009.3916215-1-m.szyprowski@samsung.com Link: https://lkml.kernel.org/r/20251009141508.2342138-1-m.szyprowski@samsung.com Fixes: 370645f41e6e ("dma-mapping: force bouncing if the kmalloc() size is not cache-line-aligned") Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> Reviewed-by: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Inki Dae <m.szyprowski(a)samsung.com> Cc: Robin Murohy <robin.murphy(a)arm.com> Cc: "Isaac J. Manjarres" <isaacmanjarres(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/dma/debug.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/kernel/dma/debug.c~dma-debug-dont-report-false-positives-with-dma_bounce_unaligned_kmalloc +++ a/kernel/dma/debug.c @@ -23,6 +23,7 @@ #include <linux/ctype.h> #include <linux/list.h> #include <linux/slab.h> +#include <linux/swiotlb.h> #include <asm/sections.h> #include "debug.h" @@ -594,7 +595,9 @@ static void add_dma_entry(struct dma_deb if (rc == -ENOMEM) { pr_err_once("cacheline tracking ENOMEM, dma-debug disabled\n"); global_disable = true; - } else if (rc == -EEXIST && !(attrs & DMA_ATTR_SKIP_CPU_SYNC)) { + } else if (rc == -EEXIST && !(attrs & DMA_ATTR_SKIP_CPU_SYNC) && + !(IS_ENABLED(CONFIG_DMA_BOUNCE_UNALIGNED_KMALLOC) && + is_swiotlb_active(entry->dev))) { err_printk(entry->dev, entry, "cacheline tracking EEXIST, overlapping mappings aren't supported\n"); } _ Patches currently in -mm which might be from m.szyprowski(a)samsung.com are

2 weeks, 6 days

1
0
0 0

[merged mm-hotfixes-stable] mm-damon-sysfs-catch-commit-test-ctx-alloc-failure.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/damon/sysfs: catch commit test ctx alloc failure has been removed from the -mm tree. Its filename was mm-damon-sysfs-catch-commit-test-ctx-alloc-failure.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: catch commit test ctx alloc failure Date: Fri, 3 Oct 2025 13:14:54 -0700 Patch series "mm/damon/sysfs: fix commit test damon_ctx [de]allocation". DAMON sysfs interface dynamically allocates and uses a damon_ctx object for testing if given inputs for online DAMON parameters update is valid. The object is being used without an allocation failure check, and leaked when the test succeeds. Fix the two bugs. This patch (of 2): The damon_ctx for testing online DAMON parameters commit inputs is used without its allocation failure check. This could result in an invalid memory access. Fix it by directly returning an error when the allocation failed. Link: https://lkml.kernel.org/r/20251003201455.41448-1-sj@kernel.org Link: https://lkml.kernel.org/r/20251003201455.41448-2-sj@kernel.org Fixes: 4c9ea539ad59 ("mm/damon/sysfs: validate user inputs from damon_sysfs_commit_input()") Signed-off-by: SeongJae Park <sj(a)kernel.org> Cc: <stable(a)vger.kernel.org> [6.15+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/damon/sysfs.c | 2 ++ 1 file changed, 2 insertions(+) --- a/mm/damon/sysfs.c~mm-damon-sysfs-catch-commit-test-ctx-alloc-failure +++ a/mm/damon/sysfs.c @@ -1473,6 +1473,8 @@ static int damon_sysfs_commit_input(void if (IS_ERR(param_ctx)) return PTR_ERR(param_ctx); test_ctx = damon_new_ctx(); + if (!test_ctx) + return -ENOMEM; err = damon_commit_ctx(test_ctx, param_ctx); if (err) { damon_destroy_ctx(test_ctx); _ Patches currently in -mm which might be from sj(a)kernel.org are mm-damon-core-fix-list_add_tail-call-on-damon_call.patch mm-damon-core-use-damos_commit_quota_goal-for-new-goal-commit.patch mm-zswap-remove-unnecessary-dlen-writes-for-incompressible-pages.patch mm-zswap-fix-typos-s-zwap-zswap.patch mm-zswap-s-red-black-tree-xarray.patch docs-admin-guide-mm-zswap-s-red-black-tree-xarray.patch

2 weeks, 6 days

1
0
0 0

[merged mm-hotfixes-stable] mm-damon-sysfs-dealloc-commit-test-ctx-always.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/damon/sysfs: dealloc commit test ctx always has been removed from the -mm tree. Its filename was mm-damon-sysfs-dealloc-commit-test-ctx-always.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: dealloc commit test ctx always Date: Fri, 3 Oct 2025 13:14:55 -0700 The damon_ctx for testing online DAMON parameters commit inputs is deallocated only when the test fails. This means memory is leaked for every successful online DAMON parameters commit. Fix the leak by always deallocating it. Link: https://lkml.kernel.org/r/20251003201455.41448-3-sj@kernel.org Fixes: 4c9ea539ad59 ("mm/damon/sysfs: validate user inputs from damon_sysfs_commit_input()") Signed-off-by: SeongJae Park <sj(a)kernel.org> Cc: <stable(a)vger.kernel.org> [6.15+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/damon/sysfs.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) --- a/mm/damon/sysfs.c~mm-damon-sysfs-dealloc-commit-test-ctx-always +++ a/mm/damon/sysfs.c @@ -1476,12 +1476,11 @@ static int damon_sysfs_commit_input(void if (!test_ctx) return -ENOMEM; err = damon_commit_ctx(test_ctx, param_ctx); - if (err) { - damon_destroy_ctx(test_ctx); + if (err) goto out; - } err = damon_commit_ctx(kdamond->damon_ctx, param_ctx); out: + damon_destroy_ctx(test_ctx); damon_destroy_ctx(param_ctx); return err; } _ Patches currently in -mm which might be from sj(a)kernel.org are mm-damon-core-fix-list_add_tail-call-on-damon_call.patch mm-damon-core-use-damos_commit_quota_goal-for-new-goal-commit.patch mm-zswap-remove-unnecessary-dlen-writes-for-incompressible-pages.patch mm-zswap-fix-typos-s-zwap-zswap.patch mm-zswap-s-red-black-tree-xarray.patch docs-admin-guide-mm-zswap-s-red-black-tree-xarray.patch

2 weeks, 6 days

1
0
0 0

[merged mm-hotfixes-stable] hung_task-fix-warnings-caused-by-unaligned-lock-pointers.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: hung_task: fix warnings caused by unaligned lock pointers has been removed from the -mm tree. Its filename was hung_task-fix-warnings-caused-by-unaligned-lock-pointers.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: Lance Yang <lance.yang(a)linux.dev> Subject: hung_task: fix warnings caused by unaligned lock pointers Date: Tue, 9 Sep 2025 22:52:43 +0800 From: Lance Yang <lance.yang(a)linux.dev> The blocker tracking mechanism assumes that lock pointers are at least 4-byte aligned to use their lower bits for type encoding. However, as reported by Eero Tamminen, some architectures like m68k only guarantee 2-byte alignment of 32-bit values. This breaks the assumption and causes two related WARN_ON_ONCE checks to trigger. To fix this, the runtime checks are adjusted to silently ignore any lock that is not 4-byte aligned, effectively disabling the feature in such cases and avoiding the related warnings. Thanks to Geert Uytterhoeven for bisecting! Link: https://lkml.kernel.org/r/20250909145243.17119-1-lance.yang@linux.dev Fixes: e711faaafbe5 ("hung_task: replace blocker_mutex with encoded blocker") Signed-off-by: Lance Yang <lance.yang(a)linux.dev> Reported-by: Eero Tamminen <oak(a)helsinkinet.fi> Closes: https://lore.kernel.org/lkml/CAMuHMdW7Ab13DdGs2acMQcix5ObJK0O2dG_Fxzr8_g58R… Reviewed-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Cc: John Paul Adrian Glaubitz <glaubitz(a)physik.fu-berlin.de> Cc: Anna Schumaker <anna.schumaker(a)oracle.com> Cc: Boqun Feng <boqun.feng(a)gmail.com> Cc: Finn Thain <fthain(a)linux-m68k.org> Cc: Geert Uytterhoeven <geert(a)linux-m68k.org> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Joel Granados <joel.granados(a)kernel.org> Cc: John Stultz <jstultz(a)google.com> Cc: Kent Overstreet <kent.overstreet(a)linux.dev> Cc: Lance Yang <lance.yang(a)linux.dev> Cc: Mingzhe Yang <mingzhe.yang(a)ly.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Sergey Senozhatsky <senozhatsky(a)chromium.org> Cc: Steven Rostedt <rostedt(a)goodmis.org> Cc: Tomasz Figa <tfiga(a)chromium.org> Cc: Waiman Long <longman(a)redhat.com> Cc: Will Deacon <will(a)kernel.org> Cc: Yongliang Gao <leonylgao(a)tencent.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/hung_task.h | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/include/linux/hung_task.h~hung_task-fix-warnings-caused-by-unaligned-lock-pointers +++ a/include/linux/hung_task.h @@ -20,6 +20,10 @@ * always zero. So we can use these bits to encode the specific blocking * type. * + * Note that on architectures where this is not guaranteed, or for any + * unaligned lock, this tracking mechanism is silently skipped for that + * lock. + * * Type encoding: * 00 - Blocked on mutex (BLOCKER_TYPE_MUTEX) * 01 - Blocked on semaphore (BLOCKER_TYPE_SEM) @@ -45,7 +49,7 @@ static inline void hung_task_set_blocker * If the lock pointer matches the BLOCKER_TYPE_MASK, return * without writing anything. */ - if (WARN_ON_ONCE(lock_ptr & BLOCKER_TYPE_MASK)) + if (lock_ptr & BLOCKER_TYPE_MASK) return; WRITE_ONCE(current->blocker, lock_ptr | type); @@ -53,8 +57,6 @@ static inline void hung_task_set_blocker static inline void hung_task_clear_blocker(void) { - WARN_ON_ONCE(!READ_ONCE(current->blocker)); - WRITE_ONCE(current->blocker, 0UL); } _ Patches currently in -mm which might be from lance.yang(a)linux.dev are

2 weeks, 6 days

1
0
0 0

FAILED: patch "[PATCH] cpufreq: Make drivers using CPUFREQ_ETERNAL specify" 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 f97aef092e199c10a3da96ae79b571edd5362faa # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025101528-barcode-doorstop-420a@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f97aef092e199c10a3da96ae79b571edd5362faa Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com> Date: Fri, 26 Sep 2025 12:12:37 +0200 Subject: [PATCH] cpufreq: Make drivers using CPUFREQ_ETERNAL specify transition latency Commit a755d0e2d41b ("cpufreq: Honour transition_latency over transition_delay_us") caused platforms where cpuinfo.transition_latency is CPUFREQ_ETERNAL to get a very large transition latency whereas previously it had been capped at 10 ms (and later at 2 ms). This led to a user-observable regression between 6.6 and 6.12 as described by Shawn: "The dbs sampling_rate was 10000 us on 6.6 and suddently becomes 6442450 us (4294967295 / 1000 * 1.5) on 6.12 for these platforms because the default transition delay was dropped [...]. It slows down dbs governor's reacting to CPU loading change dramatically. Also, as transition_delay_us is used by schedutil governor as rate_limit_us, it shows a negative impact on device idle power consumption, because the device gets slightly less time in the lowest OPP." Evidently, the expectation of the drivers using CPUFREQ_ETERNAL as cpuinfo.transition_latency was that it would be capped by the core, but they may as well return a default transition latency value instead of CPUFREQ_ETERNAL and the core need not do anything with it. Accordingly, introduce CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS and make all of the drivers in question use it instead of CPUFREQ_ETERNAL. Also update the related Rust binding. Fixes: a755d0e2d41b ("cpufreq: Honour transition_latency over transition_delay_us") Closes: https://lore.kernel.org/linux-pm/20250922125929.453444-1-shawnguo2@yeah.net/ Reported-by: Shawn Guo <shawnguo(a)kernel.org> Reviewed-by: Mario Limonciello (AMD) <superm1(a)kernel.org> Reviewed-by: Jie Zhan <zhanjie9(a)hisilicon.com> Acked-by: Viresh Kumar <viresh.kumar(a)linaro.org> Cc: 6.6+ <stable(a)vger.kernel.org> # 6.6+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Link: https://patch.msgid.link/2264949.irdbgypaU6@rafael.j.wysocki [ rjw: Fix typo in new symbol name, drop redundant type cast from Rust binding ] Tested-by: Shawn Guo <shawnguo(a)kernel.org> # with cpufreq-dt driver Reviewed-by: Qais Yousef <qyousef(a)layalina.io> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c index 506437489b4d..7d5079fd1688 100644 --- a/drivers/cpufreq/cpufreq-dt.c +++ b/drivers/cpufreq/cpufreq-dt.c @@ -104,7 +104,7 @@ static int cpufreq_init(struct cpufreq_policy *policy) transition_latency = dev_pm_opp_get_max_transition_latency(cpu_dev); if (!transition_latency) - transition_latency = CPUFREQ_ETERNAL; + transition_latency = CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS; cpumask_copy(policy->cpus, priv->cpus); policy->driver_data = priv; diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c index db1c88e9d3f9..e93697d3edfd 100644 --- a/drivers/cpufreq/imx6q-cpufreq.c +++ b/drivers/cpufreq/imx6q-cpufreq.c @@ -442,7 +442,7 @@ static int imx6q_cpufreq_probe(struct platform_device *pdev) } if (of_property_read_u32(np, "clock-latency", &transition_latency)) - transition_latency = CPUFREQ_ETERNAL; + transition_latency = CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS; /* * Calculate the ramp time for max voltage change in the diff --git a/drivers/cpufreq/mediatek-cpufreq-hw.c b/drivers/cpufreq/mediatek-cpufreq-hw.c index fce5aa5ceea0..ae4500ab4891 100644 --- a/drivers/cpufreq/mediatek-cpufreq-hw.c +++ b/drivers/cpufreq/mediatek-cpufreq-hw.c @@ -309,7 +309,7 @@ static int mtk_cpufreq_hw_cpu_init(struct cpufreq_policy *policy) latency = readl_relaxed(data->reg_bases[REG_FREQ_LATENCY]) * 1000; if (!latency) - latency = CPUFREQ_ETERNAL; + latency = CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS; policy->cpuinfo.transition_latency = latency; policy->fast_switch_possible = true; diff --git a/drivers/cpufreq/rcpufreq_dt.rs b/drivers/cpufreq/rcpufreq_dt.rs index 7e1fbf9a091f..3909022e1c74 100644 --- a/drivers/cpufreq/rcpufreq_dt.rs +++ b/drivers/cpufreq/rcpufreq_dt.rs @@ -123,7 +123,7 @@ fn init(policy: &mut cpufreq::Policy) -> Result<Self::PData> { let mut transition_latency = opp_table.max_transition_latency_ns() as u32; if transition_latency == 0 { - transition_latency = cpufreq::ETERNAL_LATENCY_NS; + transition_latency = cpufreq::DEFAULT_TRANSITION_LATENCY_NS; } policy diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c index 38c165d526d1..d2a110079f5f 100644 --- a/drivers/cpufreq/scmi-cpufreq.c +++ b/drivers/cpufreq/scmi-cpufreq.c @@ -294,7 +294,7 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy) latency = perf_ops->transition_latency_get(ph, domain); if (!latency) - latency = CPUFREQ_ETERNAL; + latency = CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS; policy->cpuinfo.transition_latency = latency; diff --git a/drivers/cpufreq/scpi-cpufreq.c b/drivers/cpufreq/scpi-cpufreq.c index dcbb0ae7dd47..e530345baddf 100644 --- a/drivers/cpufreq/scpi-cpufreq.c +++ b/drivers/cpufreq/scpi-cpufreq.c @@ -157,7 +157,7 @@ static int scpi_cpufreq_init(struct cpufreq_policy *policy) latency = scpi_ops->get_transition_latency(cpu_dev); if (!latency) - latency = CPUFREQ_ETERNAL; + latency = CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS; policy->cpuinfo.transition_latency = latency; diff --git a/drivers/cpufreq/spear-cpufreq.c b/drivers/cpufreq/spear-cpufreq.c index 707c71090cc3..2a1550e1aa21 100644 --- a/drivers/cpufreq/spear-cpufreq.c +++ b/drivers/cpufreq/spear-cpufreq.c @@ -182,7 +182,7 @@ static int spear_cpufreq_probe(struct platform_device *pdev) if (of_property_read_u32(np, "clock-latency", &spear_cpufreq.transition_latency)) - spear_cpufreq.transition_latency = CPUFREQ_ETERNAL; + spear_cpufreq.transition_latency = CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS; cnt = of_property_count_u32_elems(np, "cpufreq_tbl"); if (cnt <= 0) { diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index 40966512ea18..bc8c083bc16a 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -32,6 +32,9 @@ */ #define CPUFREQ_ETERNAL (-1) + +#define CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS NSEC_PER_MSEC + #define CPUFREQ_NAME_LEN 16 /* Print length for names. Extra 1 space for accommodating '\n' in prints */ #define CPUFREQ_NAME_PLEN (CPUFREQ_NAME_LEN + 1) diff --git a/rust/kernel/cpufreq.rs b/rust/kernel/cpufreq.rs index eea57ba95f24..2ea735700ae7 100644 --- a/rust/kernel/cpufreq.rs +++ b/rust/kernel/cpufreq.rs @@ -39,7 +39,8 @@ const CPUFREQ_NAME_LEN: usize = bindings::CPUFREQ_NAME_LEN as usize; /// Default transition latency value in nanoseconds. -pub const ETERNAL_LATENCY_NS: u32 = bindings::CPUFREQ_ETERNAL as u32; +pub const DEFAULT_TRANSITION_LATENCY_NS: u32 = + bindings::CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS; /// CPU frequency driver flags. pub mod flags { @@ -400,13 +401,13 @@ pub fn to_table(mut self) -> Result<TableBox> { /// The following example demonstrates how to create a CPU frequency table. /// /// ``` -/// use kernel::cpufreq::{ETERNAL_LATENCY_NS, Policy}; +/// use kernel::cpufreq::{DEFAULT_TRANSITION_LATENCY_NS, Policy}; /// /// fn update_policy(policy: &mut Policy) { /// policy /// .set_dvfs_possible_from_any_cpu(true) /// .set_fast_switch_possible(true) -/// .set_transition_latency_ns(ETERNAL_LATENCY_NS); +/// .set_transition_latency_ns(DEFAULT_TRANSITION_LATENCY_NS); /// /// pr_info!("The policy details are: {:?}\n", (policy.cpu(), policy.cur())); /// }

2 weeks, 6 days

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2025