From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org,yuzhao@google.com,yuanchu@google.com,weixugc@google.com,stable@vger.kernel.org,shakeel.butt@linux.dev,rlmenge@gmail.com,qi.zheng@linux.dev,mhocko@kernel.org,ljs@kernel.org,kasong@tencent.com,hargar@linux.microsoft.com,hannes@cmpxchg.org,david@kernel.org,baoquan.he@linux.dev,baolin.wang@linux.alibaba.com,baohua@kernel.org,axelrasmussen@google.com,apais@microsoft.com,sidchintamaneni@gmail.com,akpm@linux-foundation.org
Subject: [merged mm-stable] mm-multi-gen-lru-fix-null-lruvec-pgdat-deref-with-memcg-disabled-on-cmdline.patch removed from -mm tree
Date: Sat, 24 Oct 2026 02:02:28 -0700 [thread overview]
Message-ID: <20261024090229.50BA51F01828@smtp.kernel.org> (raw)
The quilt patch titled
Subject: mm: multi-gen LRU: fix NULL lruvec->pgdat deref with memcg disabled on cmdline
has been removed from the -mm tree. Its filename was
mm-multi-gen-lru-fix-null-lruvec-pgdat-deref-with-memcg-disabled-on-cmdline.patch
This patch was dropped because it was merged into the mm-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Siddharth Chintamaneni <sidchintamaneni@gmail.com>
Subject: mm: multi-gen LRU: fix NULL lruvec->pgdat deref with memcg disabled on cmdline
Date: Sat, 17 Oct 2026 05:09:27 +0000
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+
---
mm/vmscan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/vmscan.c~mm-multi-gen-lru-fix-null-lruvec-pgdat-deref-with-memcg-disabled-on-cmdline
+++ a/mm/vmscan.c
@@ -5454,7 +5454,7 @@ static void lru_gen_shrink_node(struct p
sc->nr_reclaimed = 0;
if (mem_cgroup_disabled())
- shrink_one(&pgdat->__lruvec, sc);
+ shrink_one(mem_cgroup_lruvec(NULL, pgdat), sc);
else
shrink_many(pgdat, sc);
_
Patches currently in -mm which might be from sidchintamaneni@gmail.com are
reply other threads:[~2026-10-24 9:02 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261024090229.50BA51F01828@smtp.kernel.org \
--to=akpm@linux-foundation.org \
--cc=apais@microsoft.com \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=baoquan.he@linux.dev \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=hargar@linux.microsoft.com \
--cc=kasong@tencent.com \
--cc=ljs@kernel.org \
--cc=mhocko@kernel.org \
--cc=mm-commits@vger.kernel.org \
--cc=qi.zheng@linux.dev \
--cc=rlmenge@gmail.com \
--cc=shakeel.butt@linux.dev \
--cc=sidchintamaneni@gmail.com \
--cc=stable@vger.kernel.org \
--cc=weixugc@google.com \
--cc=yuanchu@google.com \
--cc=yuzhao@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox