- Linux-stable-mirror - lists.linaro.org

[merged mm-hotfixes-stable] mm-vmalloc-leave-lazy-mmu-mode-on-pte-mapping-error.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/vmalloc: leave lazy MMU mode on PTE mapping error has been removed from the -mm tree. Its filename was mm-vmalloc-leave-lazy-mmu-mode-on-pte-mapping-error.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Alexander Gordeev <agordeev(a)linux.ibm.com> Subject: mm/vmalloc: leave lazy MMU mode on PTE mapping error Date: Mon, 23 Jun 2025 09:57:21 +0200 vmap_pages_pte_range() enters the lazy MMU mode, but fails to leave it in case an error is encountered. Link: https://lkml.kernel.org/r/20250623075721.2817094-1-agordeev@linux.ibm.com Fixes: 2ba3e6947aed ("mm/vmalloc: track which page-table levels were modified") Signed-off-by: Alexander Gordeev <agordeev(a)linux.ibm.com> Reported-by: kernel test robot <lkp(a)intel.com> Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org> Closes: https://lore.kernel.org/r/202506132017.T1l1l6ME-lkp@intel.com/ Reviewed-by: Ryan Roberts <ryan.roberts(a)arm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/vmalloc.c | 22 +++++++++++++++------- 1 file changed, 15 insertions(+), 7 deletions(-) --- a/mm/vmalloc.c~mm-vmalloc-leave-lazy-mmu-mode-on-pte-mapping-error +++ a/mm/vmalloc.c @@ -514,6 +514,7 @@ static int vmap_pages_pte_range(pmd_t *p unsigned long end, pgprot_t prot, struct page **pages, int *nr, pgtbl_mod_mask *mask) { + int err = 0; pte_t *pte; /* @@ -530,12 +531,18 @@ static int vmap_pages_pte_range(pmd_t *p do { struct page *page = pages[*nr]; - if (WARN_ON(!pte_none(ptep_get(pte)))) - return -EBUSY; - if (WARN_ON(!page)) - return -ENOMEM; - if (WARN_ON(!pfn_valid(page_to_pfn(page)))) - return -EINVAL; + if (WARN_ON(!pte_none(ptep_get(pte)))) { + err = -EBUSY; + break; + } + if (WARN_ON(!page)) { + err = -ENOMEM; + break; + } + if (WARN_ON(!pfn_valid(page_to_pfn(page)))) { + err = -EINVAL; + break; + } set_pte_at(&init_mm, addr, pte, mk_pte(page, prot)); (*nr)++; @@ -543,7 +550,8 @@ static int vmap_pages_pte_range(pmd_t *p arch_leave_lazy_mmu_mode(); *mask |= PGTBL_PTE_MODIFIED; - return 0; + + return err; } static int vmap_pages_pmd_range(pud_t *pud, unsigned long addr, _ Patches currently in -mm which might be from agordeev(a)linux.ibm.com are

3 months, 3 weeks

1
0
0 0

[merged mm-hotfixes-stable] scripts-gdb-fix-interrupts-display-after-mcp-on-x86.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: scripts/gdb: fix interrupts display after MCP on x86 has been removed from the -mm tree. Its filename was scripts-gdb-fix-interrupts-display-after-mcp-on-x86.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: Florian Fainelli <florian.fainelli(a)broadcom.com> Subject: scripts/gdb: fix interrupts display after MCP on x86 Date: Mon, 23 Jun 2025 09:41:52 -0700 The text line would not be appended to as it should have, it should have been a '+=' but ended up being a '==', fix that. Link: https://lkml.kernel.org/r/20250623164153.746359-1-florian.fainelli@broadcom… Fixes: b0969d7687a7 ("scripts/gdb: print interrupts") Signed-off-by: Florian Fainelli <florian.fainelli(a)broadcom.com> Cc: Jan Kiszka <jan.kiszka(a)siemens.com> Cc: Kieran Bingham <kbingham(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- scripts/gdb/linux/interrupts.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/scripts/gdb/linux/interrupts.py~scripts-gdb-fix-interrupts-display-after-mcp-on-x86 +++ a/scripts/gdb/linux/interrupts.py @@ -142,7 +142,7 @@ def x86_show_interupts(prec): if constants.LX_CONFIG_X86_MCE: text += x86_show_mce(prec, "&mce_exception_count", "MCE", "Machine check exceptions") - text == x86_show_mce(prec, "&mce_poll_count", "MCP", "Machine check polls") + text += x86_show_mce(prec, "&mce_poll_count", "MCP", "Machine check polls") text += show_irq_err_count(prec) _ Patches currently in -mm which might be from florian.fainelli(a)broadcom.com are

3 months, 3 weeks

1
0
0 0

[merged mm-hotfixes-stable] lib-alloc_tag-do-not-acquire-non-existent-lock-in-alloc_tag_top_users.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: lib/alloc_tag: do not acquire non-existent lock in alloc_tag_top_users() has been removed from the -mm tree. Its filename was lib-alloc_tag-do-not-acquire-non-existent-lock-in-alloc_tag_top_users.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: Harry Yoo <harry.yoo(a)oracle.com> Subject: lib/alloc_tag: do not acquire non-existent lock in alloc_tag_top_users() Date: Sat, 21 Jun 2025 04:53:05 +0900 alloc_tag_top_users() attempts to lock alloc_tag_cttype->mod_lock even when the alloc_tag_cttype is not allocated because: 1) alloc tagging is disabled because mem profiling is disabled (!alloc_tag_cttype) 2) alloc tagging is enabled, but not yet initialized (!alloc_tag_cttype) 3) alloc tagging is enabled, but failed initialization (!alloc_tag_cttype or IS_ERR(alloc_tag_cttype)) In all cases, alloc_tag_cttype is not allocated, and therefore alloc_tag_top_users() should not attempt to acquire the semaphore. This leads to a crash on memory allocation failure by attempting to acquire a non-existent semaphore: Oops: general protection fault, probably for non-canonical address 0xdffffc000000001b: 0000 [#3] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x00000000000000d8-0x00000000000000df] CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: G D 6.16.0-rc2 #1 VOLUNTARY Tainted: [D]=DIE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:down_read_trylock+0xaa/0x3b0 Code: d0 7c 08 84 d2 0f 85 a0 02 00 00 8b 0d df 31 dd 04 85 c9 75 29 48 b8 00 00 00 00 00 fc ff df 48 8d 6b 68 48 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 88 02 00 00 48 3b 5b 68 0f 85 53 01 00 00 65 ff RSP: 0000:ffff8881002ce9b8 EFLAGS: 00010016 RAX: dffffc0000000000 RBX: 0000000000000070 RCX: 0000000000000000 RDX: 000000000000001b RSI: 000000000000000a RDI: 0000000000000070 RBP: 00000000000000d8 R08: 0000000000000001 R09: ffffed107dde49d1 R10: ffff8883eef24e8b R11: ffff8881002cec20 R12: 1ffff11020059d37 R13: 00000000003fff7b R14: ffff8881002cec20 R15: dffffc0000000000 FS: 00007f963f21d940(0000) GS:ffff888458ca6000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f963f5edf71 CR3: 000000010672c000 CR4: 0000000000350ef0 Call Trace: <TASK> codetag_trylock_module_list+0xd/0x20 alloc_tag_top_users+0x369/0x4b0 __show_mem+0x1cd/0x6e0 warn_alloc+0x2b1/0x390 __alloc_frozen_pages_noprof+0x12b9/0x21a0 alloc_pages_mpol+0x135/0x3e0 alloc_slab_page+0x82/0xe0 new_slab+0x212/0x240 ___slab_alloc+0x82a/0xe00 </TASK> As David Wang points out, this issue became easier to trigger after commit 780138b12381 ("alloc_tag: check mem_profiling_support in alloc_tag_init"). Before the commit, the issue occurred only when it failed to allocate and initialize alloc_tag_cttype or if a memory allocation fails before alloc_tag_init() is called. After the commit, it can be easily triggered when memory profiling is compiled but disabled at boot. To properly determine whether alloc_tag_init() has been called and its data structures initialized, verify that alloc_tag_cttype is a valid pointer before acquiring the semaphore. If the variable is NULL or an error value, it has not been properly initialized. In such a case, just skip and do not attempt to acquire the semaphore. [harry.yoo(a)oracle.com: v3] Link: https://lkml.kernel.org/r/20250624072513.84219-1-harry.yoo@oracle.com Link: https://lkml.kernel.org/r/20250620195305.1115151-1-harry.yoo@oracle.com Fixes: 780138b12381 ("alloc_tag: check mem_profiling_support in alloc_tag_init") Fixes: 1438d349d16b ("lib: add memory allocations report in show_mem()") Signed-off-by: Harry Yoo <harry.yoo(a)oracle.com> Reported-by: kernel test robot <oliver.sang(a)intel.com> Closes: https://lore.kernel.org/oe-lkp/202506181351.bba867dd-lkp@intel.com Acked-by: Suren Baghdasaryan <surenb(a)google.com> Tested-by: Raghavendra K T <raghavendra.kt(a)amd.com> Cc: Casey Chen <cachen(a)purestorage.com> Cc: David Wang <00107082(a)163.com> Cc: Kent Overstreet <kent.overstreet(a)linux.dev> Cc: Yuanyuan Zhong <yzhong(a)purestorage.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/alloc_tag.c | 3 +++ 1 file changed, 3 insertions(+) --- a/lib/alloc_tag.c~lib-alloc_tag-do-not-acquire-non-existent-lock-in-alloc_tag_top_users +++ a/lib/alloc_tag.c @@ -135,6 +135,9 @@ size_t alloc_tag_top_users(struct codeta struct codetag_bytes n; unsigned int i, nr = 0; + if (IS_ERR_OR_NULL(alloc_tag_cttype)) + return 0; + if (can_sleep) codetag_lock_module_list(alloc_tag_cttype, true); else if (!codetag_trylock_module_list(alloc_tag_cttype)) _ Patches currently in -mm which might be from harry.yoo(a)oracle.com are mm-zsmalloc-do-not-pass-__gfp_movable-if-config_compaction=n.patch mm-check-if-folio-has-valid-mapcount-before-folio_test_anonksm-when-necessary.patch

3 months, 3 weeks

1
0
0 0

[merged mm-hotfixes-stable] kallsyms-fix-build-without-execinfo.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: kallsyms: fix build without execinfo has been removed from the -mm tree. Its filename was kallsyms-fix-build-without-execinfo.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: Achill Gilgenast <fossdd(a)pwned.life> Subject: kallsyms: fix build without execinfo Date: Sun, 22 Jun 2025 03:45:49 +0200 Some libc's like musl libc don't provide execinfo.h since it's not part of POSIX. In order to fix compilation on musl, only include execinfo.h if available (HAVE_BACKTRACE_SUPPORT) This was discovered with c104c16073b7 ("Kunit to check the longest symbol length") which starts to include linux/kallsyms.h with Alpine Linux' configs. Link: https://lkml.kernel.org/r/20250622014608.448718-1-fossdd@pwned.life Fixes: c104c16073b7 ("Kunit to check the longest symbol length") Signed-off-by: Achill Gilgenast <fossdd(a)pwned.life> Cc: Luis Henriques <luis(a)igalia.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/include/linux/kallsyms.h | 4 ++++ 1 file changed, 4 insertions(+) --- a/tools/include/linux/kallsyms.h~kallsyms-fix-build-without-execinfo +++ a/tools/include/linux/kallsyms.h @@ -18,6 +18,7 @@ static inline const char *kallsyms_looku return NULL; } +#ifdef HAVE_BACKTRACE_SUPPORT #include <execinfo.h> #include <stdlib.h> static inline void print_ip_sym(const char *loglvl, unsigned long ip) @@ -30,5 +31,8 @@ static inline void print_ip_sym(const ch free(name); } +#else +static inline void print_ip_sym(const char *loglvl, unsigned long ip) {} +#endif #endif _ Patches currently in -mm which might be from fossdd(a)pwned.life are

3 months, 3 weeks

1
0
0 0

[folded-merged] lib-alloc_tag-do-not-acquire-non-existent-lock-in-alloc_tag_top_users-v3.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: lib-alloc_tag-do-not-acquire-non-existent-lock-in-alloc_tag_top_users-v3 has been removed from the -mm tree. Its filename was lib-alloc_tag-do-not-acquire-non-existent-lock-in-alloc_tag_top_users-v3.patch This patch was dropped because it was folded into lib-alloc_tag-do-not-acquire-non-existent-lock-in-alloc_tag_top_users.patch ------------------------------------------------------ From: Harry Yoo <harry.yoo(a)oracle.com> Subject: lib-alloc_tag-do-not-acquire-non-existent-lock-in-alloc_tag_top_users-v3 Date: Tue, 24 Jun 2025 16:25:13 +0900 Link: https://lkml.kernel.org/r/20250624072513.84219-1-harry.yoo@oracle.com Reported-by: kernel test robot <oliver.sang(a)intel.com> Closes: https://lore.kernel.org/oe-lkp/202506181351.bba867dd-lkp@intel.com Closes: https://lore.kernel.org/oe-lkp/202506131711.5b41931c-lkp@intel.com Fixes: 780138b12381 ("alloc_tag: check mem_profiling_support in alloc_tag_init") Fixes: 1438d349d16b ("lib: add memory allocations report in show_mem()") Signed-off-by: Harry Yoo <harry.yoo(a)oracle.com> Cc: Casey Chen <cachen(a)purestorage.com> Cc: David Wang <00107082(a)163.com> Cc: Kent Overstreet <kent.overstreet(a)linux.dev> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Yuanyuan Zhong <yzhong(a)purestorage.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/alloc_tag.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/lib/alloc_tag.c~lib-alloc_tag-do-not-acquire-non-existent-lock-in-alloc_tag_top_users-v3 +++ a/lib/alloc_tag.c @@ -137,7 +137,8 @@ size_t alloc_tag_top_users(struct codeta if (IS_ERR_OR_NULL(alloc_tag_cttype)) return 0; - else if (can_sleep) + + if (can_sleep) codetag_lock_module_list(alloc_tag_cttype, true); else if (!codetag_trylock_module_list(alloc_tag_cttype)) return 0; _ Patches currently in -mm which might be from harry.yoo(a)oracle.com are lib-alloc_tag-do-not-acquire-non-existent-lock-in-alloc_tag_top_users.patch mm-zsmalloc-do-not-pass-__gfp_movable-if-config_compaction=n.patch mm-check-if-folio-has-valid-mapcount-before-folio_test_anonksm-when-necessary.patch

3 months, 3 weeks

1
0
0 0

+ mm-shmem-swap-improve-cached-mthp-handling-and-fix-potential-hung.patch added to mm-new branch

by Andrew Morton

The patch titled Subject: mm/shmem, swap: improve cached mTHP handling and fix potential hung has been added to the -mm mm-new branch. Its filename is mm-shmem-swap-improve-cached-mthp-handling-and-fix-potential-hung.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-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. 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: Kairui Song <kasong(a)tencent.com> Subject: mm/shmem, swap: improve cached mTHP handling and fix potential hung Date: Thu, 10 Jul 2025 11:36:59 +0800 Patch series "mm/shmem, swap: bugfix and improvement of mTHP swap in", v5. The current mTHP swapin path have several problems. It may potentially hang, may cause redundant faults due to false positive swap cache lookup, and it will involve at least 4 Xarray tree walks (get order, get order again, confirm swap, insert folio). And for !CONFIG_TRANSPARENT_HUGEPAGE builds, it will performs some mTHP related checks. This series fixes all of the mentioned issues, and the code should be more robust and prepared for the swap table series. Now tree walks is reduced to twice (get order & confirm, insert folio), !CONFIG_TRANSPARENT_HUGEPAGE build overhead is also minimized, and comes with a sanity check now. The performance is slightly better after this series, sequential swap in of 24G data from ZRAM, using transparent_hugepage_tmpfs=always (24 samples each): Before: Avg: 10.67s, stddev: 0.04 After patch 1: Avg: 10.49s, stddev: 0.04 After patch 2: Avg: 10.42s, stddev: 0.05 After patch 3: Avg: 10.45s, stddev: 0.05 After patch 4: Avg: 10.49s, stddev: 0.04 After patch 5: Avg: 9.67s, stddev: 0.03 After patch 6: Avg: 9.67s, stddev: 0.04 After patch 7: Avg: 9.68s, stddev: 0.05 After patch 8: Avg: 9.66s, stddev: 0.04 Several patches improve the performance by a little, which is about ~10% faster in total. Build kernel test showed very slightly improvement, testing with make -j48 with defconfig in a 768M memcg also using ZRAM as swap, and transparent_hugepage_tmpfs=always (6 test runs): Before: avg: 3353.66s, stddev: 33.73 After patch 1: avg: 3354.19s, stddev: 42.54 After patch 2: avg: 3364.16s, stddev: 52.74 After patch 3: avg: 3355.73s, stddev: 36.17 After patch 4: avg: 3352.78s, stddev: 39.80 After patch 5: avg: 3355.19s, stddev: 50.78 After patch 6: avg: 3333.63s, stddev: 32.50 After patch 7: avg: 3297.70s, stddev: 38.93 After patch 8: avg: 3302.35s, stddev: 50.61 This patch (of 8): The current swap-in code assumes that, when a swap entry in shmem mapping is order 0, its cached folios (if present) must be order 0 too, which turns out not always correct. The problem is shmem_split_large_entry is called before verifying the folio will eventually be swapped in, one possible race is: CPU1 CPU2 shmem_swapin_folio /* swap in of order > 0 swap entry S1 */ folio = swap_cache_get_folio /* folio = NULL */ order = xa_get_order /* order > 0 */ folio = shmem_swap_alloc_folio /* mTHP alloc failure, folio = NULL */ <... Interrupted ...> shmem_swapin_folio /* S1 is swapped in */ shmem_writeout /* S1 is swapped out, folio cached */ shmem_split_large_entry(..., S1) /* S1 is split, but the folio covering it has order > 0 now */ Now any following swapin of S1 will hang: `xa_get_order` returns 0, and folio lookup will return a folio with order > 0. The `xa_get_order(&mapping->i_pages, index) != folio_order(folio)` will always return false causing swap-in to return -EEXIST. And this looks fragile. So fix this up by allowing seeing a larger folio in swap cache, and check the whole shmem mapping range covered by the swapin have the right swap value upon inserting the folio. And drop the redundant tree walks before the insertion. This will actually improve performance, as it avoids two redundant Xarray tree walks in the hot path, and the only side effect is that in the failure path, shmem may redundantly reallocate a few folios causing temporary slight memory pressure. And worth noting, it may seems the order and value check before inserting might help reducing the lock contention, which is not true. The swap cache layer ensures raced swapin will either see a swap cache folio or failed to do a swapin (we have SWAP_HAS_CACHE bit even if swap cache is bypassed), so holding the folio lock and checking the folio flag is already good enough for avoiding the lock contention. The chance that a folio passes the swap entry value check but the shmem mapping slot has changed should be very low. Link: https://lkml.kernel.org/r/20250710033706.71042-1-ryncsn@gmail.com Link: https://lkml.kernel.org/r/20250710033706.71042-2-ryncsn@gmail.com Fixes: 809bc86517cc ("mm: shmem: support large folio swap out") Signed-off-by: Kairui Song <kasong(a)tencent.com> Reviewed-by: Kemeng Shi <shikemeng(a)huaweicloud.com> Reviewed-by: Baolin Wang <baolin.wang(a)linux.alibaba.com> Tested-by: Baolin Wang <baolin.wang(a)linux.alibaba.com> Cc: <stable(a)vger.kernel.org> Cc: Baoquan He <bhe(a)redhat.com> Cc: Chris Li <chrisl(a)kernel.org> Cc: Hugh Dickins <hughd(a)google.com> Cc: Kairui Song <kasong(a)tencent.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Nhat Pham <nphamcs(a)gmail.com> Cc: Dev Jain <dev.jain(a)arm.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/shmem.c | 30 +++++++++++++++++++++--------- 1 file changed, 21 insertions(+), 9 deletions(-) --- a/mm/shmem.c~mm-shmem-swap-improve-cached-mthp-handling-and-fix-potential-hung +++ a/mm/shmem.c @@ -884,7 +884,9 @@ static int shmem_add_to_page_cache(struc pgoff_t index, void *expected, gfp_t gfp) { XA_STATE_ORDER(xas, &mapping->i_pages, index, folio_order(folio)); - long nr = folio_nr_pages(folio); + unsigned long nr = folio_nr_pages(folio); + swp_entry_t iter, swap; + void *entry; VM_BUG_ON_FOLIO(index != round_down(index, nr), folio); VM_BUG_ON_FOLIO(!folio_test_locked(folio), folio); @@ -896,14 +898,24 @@ static int shmem_add_to_page_cache(struc gfp &= GFP_RECLAIM_MASK; folio_throttle_swaprate(folio, gfp); + swap = iter = radix_to_swp_entry(expected); do { xas_lock_irq(&xas); - if (expected != xas_find_conflict(&xas)) { - xas_set_err(&xas, -EEXIST); - goto unlock; + xas_for_each_conflict(&xas, entry) { + /* + * The range must either be empty, or filled with + * expected swap entries. Shmem swap entries are never + * partially freed without split of both entry and + * folio, so there shouldn't be any holes. + */ + if (!expected || entry != swp_to_radix_entry(iter)) { + xas_set_err(&xas, -EEXIST); + goto unlock; + } + iter.val += 1 << xas_get_order(&xas); } - if (expected && xas_find_conflict(&xas)) { + if (expected && iter.val - nr != swap.val) { xas_set_err(&xas, -EEXIST); goto unlock; } @@ -2323,7 +2335,7 @@ static int shmem_swapin_folio(struct ino error = -ENOMEM; goto failed; } - } else if (order != folio_order(folio)) { + } else if (order > folio_order(folio)) { /* * Swap readahead may swap in order 0 folios into swapcache * asynchronously, while the shmem mapping can still stores @@ -2348,15 +2360,15 @@ static int shmem_swapin_folio(struct ino swap = swp_entry(swp_type(swap), swp_offset(swap) + offset); } + } else if (order < folio_order(folio)) { + swap.val = round_down(swap.val, 1 << folio_order(folio)); } alloced: /* We have to do this with folio locked to prevent races */ folio_lock(folio); if ((!skip_swapcache && !folio_test_swapcache(folio)) || - folio->swap.val != swap.val || - !shmem_confirm_swap(mapping, index, swap) || - xa_get_order(&mapping->i_pages, index) != folio_order(folio)) { + folio->swap.val != swap.val) { error = -EEXIST; goto unlock; } _ Patches currently in -mm which might be from kasong(a)tencent.com are mm-list_lru-refactor-the-locking-code.patch mm-shmem-swap-improve-cached-mthp-handling-and-fix-potential-hung.patch mm-shmem-swap-avoid-redundant-xarray-lookup-during-swapin.patch mm-shmem-swap-tidy-up-thp-swapin-checks.patch mm-shmem-swap-tidy-up-swap-entry-splitting.patch mm-shmem-swap-never-use-swap-cache-and-readahead-for-swp_synchronous_io.patch mm-shmem-swap-simplify-swapin-path-and-result-handling.patch mm-shmem-swap-rework-swap-entry-and-index-calculation-for-large-swapin.patch mm-shmem-swap-fix-major-fault-counting.patch

3 months, 3 weeks

1
0
0 0

[PATCH v2] zynq_fpga: use sgtable-based scatterlist wrappers

by Marek Szyprowski

Use common wrappers operating directly on the struct sg_table objects to fix incorrect use of statterlists related calls. dma_unmap_sg() function has to be called with the number of elements originally passed to the dma_map_sg() function, not the one returned in sgtable's nents. CC: stable(a)vger.kernel.org Fixes: 425902f5c8e3 ("fpga zynq: Use the scatterlist interface") Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> --- v2: - fixed build break (missing flags parameter) --- drivers/fpga/zynq-fpga.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git drivers/fpga/zynq-fpga.c drivers/fpga/zynq-fpga.c index f7e08f7ea9ef..0be0d569589d 100644 --- drivers/fpga/zynq-fpga.c +++ drivers/fpga/zynq-fpga.c @@ -406,7 +406,7 @@ static int zynq_fpga_ops_write(struct fpga_manager *mgr, struct sg_table *sgt) } priv->dma_nelms = - dma_map_sg(mgr->dev.parent, sgt->sgl, sgt->nents, DMA_TO_DEVICE); + dma_map_sgtable(mgr->dev.parent, sgt, DMA_TO_DEVICE, 0); if (priv->dma_nelms == 0) { dev_err(&mgr->dev, "Unable to DMA map (TO_DEVICE)\n"); return -ENOMEM; @@ -478,7 +478,7 @@ static int zynq_fpga_ops_write(struct fpga_manager *mgr, struct sg_table *sgt) clk_disable(priv->clk); out_free: - dma_unmap_sg(mgr->dev.parent, sgt->sgl, sgt->nents, DMA_TO_DEVICE); + dma_unmap_sgtable(mgr->dev.parent, sgt, DMA_TO_DEVICE, 0); return err; } -- 2.34.1

3 months, 3 weeks

2
1
0 0

[PATCH v2 wireless-next] wifi: mt76: mt7925u: Add VID/PID for Netgear A9000

by Nick Morrow

From 17bf632a10e843af7a5f80d9e1449c5c26bb8486 Mon Sep 17 00:00:00 2001 From: Nick Morrow <morrownr(a)gmail.com> Date: Tue, 8 Jul 2025 16:40:42 -0500 Subject: [PATCH v2 wireless-next] wifi: mt76: mt7925u: Add VID/PID for Netgear A9000 Add VID/PID 0846/9072 for recently released Netgear A9000. Signed-off-by: Nick Morrow <morrownr(a)gmail.com> Cc: stable(a)vger.kernel.org --- v2: - No change. --- drivers/net/wireless/mediatek/mt76/mt7925/usb.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/usb.c b/drivers/net/wireless/mediatek/mt76/mt7925/usb.c index 4dfbc1b6cfdd..bf040f34e4b9 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/usb.c +++ b/drivers/net/wireless/mediatek/mt76/mt7925/usb.c @@ -12,6 +12,9 @@ static const struct usb_device_id mt7925u_device_table[] = { { USB_DEVICE_AND_INTERFACE_INFO(0x0e8d, 0x7925, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t)MT7925_FIRMWARE_WM }, + /* Netgear, Inc. A9000 */ + { USB_DEVICE_AND_INTERFACE_INFO(0x0846, 0x9072, 0xff, 0xff, 0xff), + .driver_info = (kernel_ulong_t)MT7925_FIRMWARE_WM }, { }, }; -- 2.48.1

3 months, 4 weeks

1
0
0 0

[PATCH 1/1] Drivers: hv: Select CONFIG_SYSFB only if EFI is enabled

by mhkelley58＠gmail.com

From: Michael Kelley <mhklinux(a)outlook.com> Commit 96959283a58d ("Drivers: hv: Always select CONFIG_SYSFB for Hyper-V guests") selects CONFIG_SYSFB for Hyper-V guests so that screen_info is available to the VMBus driver to get the location of the framebuffer in Generation 2 VMs. However, if CONFIG_HYPERV is enabled but CONFIG_EFI is not, a kernel link error results in ARM64 builds because screen_info is provided by the EFI firmware interface. While configuring an ARM64 Hyper-V guest without EFI isn't useful since EFI is required to boot, the configuration is still possible and the link error should be prevented. Fix this by making the selection of CONFIG_SYSFB conditional on CONFIG_EFI being defined. For Generation 1 VMs on x86/x64, which don't use EFI, the additional condition is OK because such VMs get the framebuffer information via a mechanism that doesn't use screen_info. Fixes: 96959283a58d ("Drivers: hv: Always select CONFIG_SYSFB for Hyper-V guests") Reported-by: Arnd Bergmann <arnd(a)arndb.de> Closes: https://lore.kernel.org/linux-hyperv/20250610091810.2638058-1-arnd@kernel.o… Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202506080820.1wmkQufc-lkp@intel.com/ Signed-off-by: Michael Kelley <mhklinux(a)outlook.com> --- drivers/hv/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig index 1cd188b73b74..57623ca7f350 100644 --- a/drivers/hv/Kconfig +++ b/drivers/hv/Kconfig @@ -9,7 +9,7 @@ config HYPERV select PARAVIRT select X86_HV_CALLBACK_VECTOR if X86 select OF_EARLY_FLATTREE if OF - select SYSFB if !HYPERV_VTL_MODE + select SYSFB if EFI && !HYPERV_VTL_MODE help Select this option to run Linux as a Hyper-V client operating system. -- 2.25.1

3 months, 4 weeks

5
4
0 0

[PATCH wireless-next] wifi: mt76: mt7925u: Add VID/PID for Netgear A9000

by Nick Morrow

From 17bf632a10e843af7a5f80d9e1449c5c26bb8486 Mon Sep 17 00:00:00 2001 From: Nick Morrow <morrownr(a)gmail.com> Date: Tue, 8 Jul 2025 16:40:42 -0500 Subject: [PATCH wireless-next] wifi: mt76: mt7925u: Add VID/PID for Netgear A9000 Add VID/PID 0846/9072 for recently released Netgear A9000. Signed-off-by: Nick Morrow <morrownr(a)gmail.com> Cc: stable(a)vger.kernel.org --- drivers/net/wireless/mediatek/mt76/mt7925/usb.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/usb.c b/drivers/net/wireless/mediatek/mt76/mt7925/usb.c index 4dfbc1b6cfdd..bf040f34e4b9 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/usb.c +++ b/drivers/net/wireless/mediatek/mt76/mt7925/usb.c @@ -12,6 +12,9 @@ static const struct usb_device_id mt7925u_device_table[] = { { USB_DEVICE_AND_INTERFACE_INFO(0x0e8d, 0x7925, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t)MT7925_FIRMWARE_WM }, + /* Netgear, Inc. A9000 */ + { USB_DEVICE_AND_INTERFACE_INFO(0x0846, 0x9072, 0xff, 0xff, 0xff), + .driver_info = (kernel_ulong_t)MT7925_FIRMWARE_WM }, { }, }; -- 2.48.1

3 months, 4 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror