Hi, On Sun, 18 Oct 2026 13:09:26 +0200, Christian Theune wrote: > Quick note: while rolling back the affected machine, I noticed that we > only saw those exact crashes on 6.12.112 but not on 6.12.110 and > 6.12.111.
Another data point: we hit the same oops twice in 30 hours on a KVM guest running Debian's 6.12.113 (kswapd -> ... -> workingset_update_node -> list_lru_add+0x83, NULL+0x8), Debian bug https://bugs.debian.org/1151281. Amazon reported it on 6.12.110. In case it helps with the 6.12 backport Greg and Sasha asked for, we have a reproducer and ran it on one test guest (8 vCPU, 8 GB, XFS on a loop device, MGLRU, THP=always), pristine 6.12.113 from kernel.org built with a reduced Debian config: kernel result with background load Debian 6.12.113-1 crashed after ~13, ~2*, ~24 min pristine 6.12.113 crashed after ~14 min pristine 6.12.113, ad812805fea7 no crash in 90 min reverted pristine 6.12.113 + 62e72d2cf702 + no crash in 120 min aca1f2d5de17 adapted (below) * that run started just after a kernel build had finished Without the background load the reproducer alone did not crash (30 and 60 min runs). During the 120 min run on the backport the path was exercised heavily (~1.09M workingset_nodereclaim, ~37k thp_split_page) and the kernel log stayed clean (no BUG/WARNING). The backport we tested follows Sasha's description: 62e72d2cf702 ("mm, madvise: fix potential workingset node list_lru leaks") applies cleanly to 6.12.113, and the relevant part of aca1f2d5de17 becomes a single line in split_huge_page_to_list_to_order(): --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -3529,6 +3529,7 @@ int split_huge_page_to_list_to_order(struct page *page, struct list_head *list, goto out; } + mapping_set_update(&xas, mapping); xas_split_alloc(&xas, folio, folio_order(folio), gfp); if (xas_error(&xas)) { ret = xas_error(&xas); This is test feedback, not a formal submission: we are not in a position to carry these patches through review ourselves. If someone sends the 6.12.y backports, we are glad to run them through the same reproducer and reply with a Tested-by. The reproducer, roughly: on an XFS filesystem, a background loop that untars the kernel source and runs "make -j$(nproc) vmlinux" in its own cgroup, plus 4 workers each looping over (1) in a MemoryMax=128M scope, rewrite a 256 MiB file in 2 MiB writes and evict it by reading a 1 GiB file (cache dropped first), then (2) in a fresh MemoryMax=96M scope, read the 256 MiB file back with read_ahead_kb=16384, punch an 8 KiB hole in every 2 MiB block and read the 1 GiB file again to force memcg reclaim. The scripts are available on request. Thanks, Thomas Mischler
