summaryrefslogtreecommitdiff
path: root/security
diff options
context:
space:
mode:
authorSiddharth Chintamaneni <sidchintamaneni@gmail.com>2026-10-17 05:09:27 +0000
committerAndrew Morton <akpm@linux-foundation.org>2026-10-24 01:56:43 -0700
commit183895979c441e52dbd651b388553b09eaa35cfa (patch)
tree608b0492c04b81a6144f75d030801253c03d39ec /security
parent51542d55bcd59d428896168fd5b99b0d32440765 (diff)
mm: multi-gen LRU: fix NULL lruvec->pgdat deref with memcg disabled on cmdline
When CONFIG_MEMCG=y, lruvec_pgdat() returns lruvec->pgdat, which for the per-node pgdat->__lruvec is left NULL by lruvec_init() and only filled in lazily by mem_cgroup_lruvec(). Normally that happens early, e.g. on the first folio_add_lru(). With cgroup_disable=memory, lru_gen_shrink_node() passes &pgdat->__lruvec directly to shrink_one(). If direct reclaim runs before anything has called mem_cgroup_lruvec() for the node, which can happen during early boot under memory pressure (e.g. a kdump kernel), get_swappiness() ends up dereferencing a NULL pgdat: Unable to handle kernel NULL pointer dereference at virtual address 0000000000005040 pc : get_swappiness+0x68/0xb0 lr : try_to_shrink_lruvec+0x54/0x2c0 Call trace: get_swappiness+0x68/0xb0 (P) try_to_shrink_lruvec+0x54/0x2c0 shrink_one+0x8c/0x240 shrink_node+0xc6c/0xe08 do_try_to_free_pages+0xdc/0x570 try_to_free_pages+0x124/0x278 __alloc_frozen_pages_noprof+0x6e8/0xf78 alloc_pages_mpol+0xc4/0x1c0 alloc_frozen_pages_noprof+0x54/0xe8 alloc_pages_noprof+0x1c/0x40 atomic_pool_expand+0x98/0x300 __dma_atomic_pool_init+0x58/0xd8 dma_atomic_pool_init+0x154/0x170 do_one_initcall+0x64/0x350 kernel_init_freeable+0x214/0x430 kernel_init+0x2c/0x208 ret_from_fork+0x10/0x20 The classic LRU path and MGLRU before per-node lru_gen_folio lists obtained the lruvec through mem_cgroup_lruvec(), which sets lruvec->pgdat. The above was hit on an arm64 kdump kernel (6.18-based) booted with cgroup_disable=memory nr_cpus=4. It also reproduces on mainline on an arm64 VM with CONFIG_ARM64_64K_PAGES=y, CONFIG_MEMCG=y, CONFIG_LRU_GEN_ENABLED=y and: mem=160M nr_cpus=4 coherent_pool=512M cgroup_disable=memory These options only serve to force direct reclaim early in boot; with 160M the boot eventually ends in OOM regardless. On mainline the first LRU reclaim happens while unpacking the initramfs, and faults the same way: Unable to handle kernel NULL pointer dereference at virtual address 0000000000005040 pc : get_swappiness+0xd4/0x150 Call trace: get_swappiness+0xd4/0x150 (P) try_to_shrink_lruvec+0x44/0x2b8 shrink_one+0x80/0x1a0 shrink_node+0xd98/0xea8 do_try_to_free_pages+0xf4/0x4b0 try_to_free_pages+0x110/0x360 __alloc_frozen_pages_noprof+0x8b0/0x1718 ... __filemap_get_folio_mpol+0x2ac/0x548 simple_write_begin+0x44/0xf8 page_symlink+0x178/0x198 ... do_populate_rootfs+0x13c/0x200 Link: https://lore.kernel.org/20261017050928.128582-1-sidchintamaneni@gmail.com Fixes: e4dde56cd208 ("mm: multi-gen LRU: per-node lru_gen_folio lists") Signed-off-by: Siddharth Chintamaneni <sidchintamaneni@gmail.com> Signed-off-by: Hardik Garg <hargar@linux.microsoft.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Barry Song <baohua@kernel.org> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Assisted-by: LLM Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: David Hildenbrand <david@kernel.org> Cc: Michal Hocko <mhocko@kernel.org> Cc: Qi Zheng <qi.zheng@linux.dev> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Kairui Song <kasong@tencent.com> Cc: Axel Rasmussen <axelrasmussen@google.com> Cc: Yuanchu Xie <yuanchu@google.com> Cc: Wei Xu <weixugc@google.com> Cc: Baoquan He <baoquan.he@linux.dev> Cc: Yu Zhao <yuzhao@google.com> Cc: <apais@microsoft.com> Cc: <rlmenge@gmail.com> Cc: <stable@vger.kernel.org> # 6.3+
Diffstat (limited to 'security')
0 files changed, 0 insertions, 0 deletions