kernel/git/next/linux-next.git/lib, branch master

Merge branch 'kunit' of https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git

2026-09-08T19:54:03+00:00

Merge branch 'non-rcu/next' of https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git

2026-09-08T19:14:14+00:00

# Conflicts: # kernel/smp.c

Merge branch 'master' of https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git

2026-09-08T15:34:34+00:00

Merge branch 'mm-nonmm-unstable' of https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

2026-09-08T12:19:38+00:00

Merge https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-unstable into for-next

2026-09-08T07:09:07+00:00

Signed-off-by: David Hildenbrand (Arm)

Merge https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-hotfixes-unstable into for-next-fixes

2026-09-08T07:09:06+00:00

Signed-off-by: David Hildenbrand (Arm)

lib/plist: fix plist_requeue() corrupting order in the last bucket

2026-09-06T03:23:31+00:00

plist_requeue() is meant to move a node to the end of its own priority run. When the node heads the *last* priority bucket it is instead placed at the head of the whole list, leaving the plist unsorted: built: A(prio 0) B(prio 1) C(prio 1) requeue(B): B(prio 1) A(prio 0) C(prio 1) expected: A(prio 0) C(prio 1) B(prio 1) prio_list is a *headless* circular ring of the nodes that lead each priority bucket. The shortcut added by commit 95d4b3450ebe ("lib/plist.c: add shortcut for plist_requeue()") takes iter = list_entry(iter->prio_list.next, struct plist_node, prio_list); node_next = &iter->node_list; which from the last bucket wraps round to the *first* bucket, so node_next ends up pointing at the head of the list rather than at its end. The plist_for_each_continue() loop immediately below it computes the correct answer (&head->node_list) for that case. With any bucket after it the shortcut is correct, which is why this went unnoticed: the benchmark in that commit measured elapsed time and never checked the resulting order. Keep the shortcut -- it is a real win -- but exclude the case where iter's bucket is the last one, which is exactly when its ring successor is the first bucket again. Reachable from mm/swapfile.c, which rotates swap_avail_heads[] with plist_requeue(). It takes three or more swap devices: at least two distinct priorities, so that a later bucket exists for the ring to wrap round from, and two or more devices sharing the lowest priority, so that plist_requeue() does not return early. One device per priority returns early at the node->prio != iter->prio test. A single priority is also safe, but for a different reason worth stating: with one bucket no node is ever linked onto prio_list at all -- plist_add() skips it for the first node and for every node whose predecessor shares its priority -- so list_empty(&iter->prio_list) holds and the shortcut is never entered. Tested by driving three implementations -- the pre-95d4b3450ebe code, current mainline, and this patch -- through 1,084,492 identical random add/del/requeue operations over 24 nodes and 1..5 distinct priorities, comparing the resulting node_list node for node after every operation: variant differs from pre-95d4b3450ebe left list unsorted pre-95d4b3450ebe -- (reference) 0 mainline 289,297 276,660 this patch 0 0 Link: https://lore.kernel.org/20260903222456.1881786-1-handyhandyman.adam@gmail.com Fixes: 95d4b3450ebe ("lib/plist.c: add shortcut for plist_requeue()") Signed-off-by: Adam Harshbarger Assisted-by: Claude:claude-opus-5 Cc: I Hsin Cheng Cc: # v6.15+ Signed-off-by: Andrew Morton

dyndbg: clean up dynamic_debug_init() to improve readability

2026-09-06T03:23:27+00:00

Keep variable assignments in the same order throughout the function to make the code easier to follow. No functional changes. Link: https://lore.kernel.org/20260811121831.577848-3-yuntao.wang@linux.dev Signed-off-by: Yuntao Wang Cc: Jason Baron Cc: Jim Cromie Signed-off-by: Andrew Morton

dyndbg: fix incorrect mod_ct value in dynamic_debug_init()

2026-09-06T03:23:27+00:00

Patch series "dyndbg: fix incorrect mod_ct value in dynamic_debug_init()". Fix and clean up dynamic_debug_init(). This patch (of 2): Suppose all `struct _ddebug` instances belong to the same module, mod_ct should be 1, but it is currently 0. mod_ct is incremented only when iter->modname changes, i.e. when the loop encounters the first _ddebug entry of a new module: if (strcmp(modname, iter->modname)) { mod_ct++; ... } If all _ddebug entries belong to the same module, strcmp() never returns nonzero, so mod_ct remains 0. However, the last (and in this case only) module is added after the loop: di.num_descs = mod_sites; di.descs = iter_mod_start; ret = ddebug_add_module(&di, modname); Thus, mod_ct should be incremented before adding this final module. The bug only affects the diagnostic message printed by vpr_info(): "%d prdebugs in %d modules, ..." It reports one fewer module than the actual number of modules. There is no userspace-visible runtime effect; the dynamic debug tables themselves are initialized correctly. Fix it. Link: https://lore.kernel.org/20260811121831.577848-1-yuntao.wang@linux.dev Link: https://lore.kernel.org/20260811121831.577848-2-yuntao.wang@linux.dev Signed-off-by: Yuntao Wang Cc: Jason Baron Cc: Jim Cromie Signed-off-by: Andrew Morton

lib: decompress_unxz: make it obvious that there is no memory leak

2026-09-06T03:23:26+00:00

Calling __decompress() or unxz() with fill == NULL && flush == NULL && in == NULL is invalid, thus there were no memory leaks even though it might have looked like that. Move the conditional free() calls so that it's obvious that there are no leaks. Link: https://lore.kernel.org/20260901014138.22699-1-skunkolee@gmail.com Signed-off-by: Ivy Lopez Closes: https://bugzilla.kernel.org/show_bug.cgi?id=207113 Link: https://lore.kernel.org/lkml/20241006072542.66442-2-t.v.s10123@gmail.com/T/ Link: https://lore.kernel.org/lkml/20260825191333.34276-1-skunkolee@gmail.com/T/ Reviewed-by: Lasse Collin Signed-off-by: Andrew Morton