[Bug 2173885] Re: 7.0.0-43-generic: NULL-pointer page fault in lruvec_stat_mod_folio() during munmap (folio_remove_rmap_ptes -> zap_pte_range), 4 panics in 10 days

Adding version.log as requested by the kernel bug guidelines. ** Attachment added: "version.log (proc/version_signature + lsb_release -rd + apt-cache policy)" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2173885/+attachment/6016719/+files/version.log -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2173885 Title: 7.0.0-43-generic: NULL-pointer page fault in lruvec_stat_mod_folio() during munmap (folio_remove_rmap_ptes -> zap_pte_range), 4 panics in 10 days Status in linux package in Ubuntu: New Bug description: ## Summary Since this machine moved to 7.0.0-42/-43 it has hit a kernel panic 4 times in 10 days (~1 in every 10 boots). Each time the kernel Oopses instantly (Ubuntu's `panic_on_oops=1`), kdump writes a vmcore and the machine reboots. Two different MM/folio code paths are involved. Dumps present in `/var/crash`: `202610311135`, `202611010006`, `202611041154`, `202611101949`. ## Latest Oops (2026-11-10 19:45:52 +0800, uptime 91 s, kernel 7.0.0-43-generic) ``` BUG: unable to handle page fault for address: 000000000002a200 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1455aa067 P4D 1455aa067 PUD 1455a9067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 1000 PID: 2913 Comm: Thread-1 (get_m Tainted: G OE 7.0.0-43-generic #43-Ubuntu PREEMPT(lazy) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. Precision 5760/0T7J1J, BIOS 1.39.0 03/31/2026 RIP: 0010:lruvec_stat_mod_folio+0x50/0x100 Code: 1c c5 a0 e9 5f a5 e8 cf d1 c7 ff 49 8b 54 24 38 48 89 d0 48 83 e0 f8 83 e2 02 74 04 48 8b 40 10 49 63 d5 48 85 c0 74 63 66 90 <48> 63 8b 00 a2 02 00 4c 8b a4 c8 80 06 00 00 49 83 c4 40 49 3b 9c RSP: 0018:ffffd196ccf7f6f0 EFLAGS: 00010286 RAX: ffff8a2a0816a1c0 RBX: 0000000000000000 RCX: ffff8a2d7260b200 RDX: ffffffffffffffff RSI: 0000000000000011 RDI: fffff27119138640 R13: 00000000ffffffff R14: 0000000000000011 R15: fffff27119138640 CR2: 000000000002a200 Call Trace: <TASK> folio_remove_rmap_ptes+0x41/0x270 zap_present_ptes.constprop.0+0x290/0x750 zap_pte_range+0x1f5/0x780 zap_pmd_range.isra.0+0xce/0x250 unmap_page_range+0x23a/0x3d0 unmap_single_vma+0x96/0x110 unmap_vmas+0xa5/0x180 unmap_region+0xa4/0x110 vms_complete_munmap_vmas+0x1f7/0x280 do_vmi_align_munmap+0x185/0x210 do_vmi_munmap+0xd1/0x1b0 __vm_munmap+0xc1/0x190 __x64_sys_munmap+0x1b/0x30 x64_sys_call+0x22a3/0x2390 do_syscall_64+0x105/0x580 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> ``` Reading of the registers: `RBX=0` and the faulting instruction is `movslq 0x2a200(%rbx),%rcx`, i.e. a NULL base plus a member offset that matches `struct mem_cgroup`; `memcg` obtained from the folio was NULL while the path still dereferenced it. `R13=0xffffffff` (−1) is the stat delta (`-nr_pages` for a single page). The `folio` pointer itself (`R15=fffff27119138640`) is a vmemmap address, so this looks like rmap accounting on a folio that is not charged to any memcg (device-private / special mapping), reached through the plain `munmap()` → `zap_pte_range()` path. The faulting task is a Python thread (`Thread-1 (get_model)`) of a local FunASR STT daemon; the `munmap()` being torn down is a ~928 MB region (`RSI=0x39f3e000`), i.e. it happens while that daemon loads model weights right after boot. The nvidia modules are loaded (taint OE), but no nvidia frame appears anywhere in the stack. ## Earlier panic on the same kernel family (2026-10-31 11:35) ``` RIP: 0010:detach_extent_buffer_folio+0x19 [btrfs] CR2=0x0000200000000018 eb->folios[i] garbage btree_release_folio → filemap_release_folio → shrink_folio_list → balance_pgdat → kswapd ``` So within 10 days two different folio/rmap/reclaim code paths died. Both look like mm regressions rather than hardware (no MCE, no I/O errors, no thermal events in dmesg; memory test not run yet, but the two signatures are in different subsystems). ## System - Ubuntu 26.04 (resolute), `7.0.0-43-generic` (7.0.14 base), 16 threads, 61 GiB RAM, 16 GiB zram - Dell Precision 5760, BIOS 1.39.0 - root on btrfs (`space_cache=v2`, `discard=async`, single device, 712 GiB used / 236 GiB free) - nvidia 595.99.02 (OOT, tainted), virtualbox 7.2.6 - Reproducible only statistically: ~1 panic per 10 boots, always during heavy allocation/free right after boot (FunASR model loading) or during kswapd reclaim ## Why I cannot bisect downwards `7.0.0-31-generic` (installed) boots, but DisplayPort-MST outputs are dead on it: KWin enumerates `eDP-1`, `DP-9`, `DP-11` (the two external monitors sit on i915 DP-MST), windows are placed on the MST outputs and the screens stay black. So 7.0.0-31 is not usable here as a control. ## Secondary issue `kdump-tools` logs `The kernel version is not supported. The makedumpfile operation may be incomplete.` while saving the vmcore (makedumpfile in the kdump initrd is older than the 7.0 kernel). dmesg extraction still works; the compressed dump is 872 MB. ## Questions / request 1. Is this a known regression in 7.0.0-42/-43 (folio/rmap accounting, `lruvec_stat_mod_folio`)? 2. Is there a fix in `-proposed` I can test? 3. I can provide the full dmesg, `/proc/vmcore`-derived dump (872 MB) or run any debug kernel. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2173885/+subscriptions