+ mm-list_lru-dont-copy-stale-shrinker-id-from-non-memcg-aware-shrinkers.patch added to mm-new branch

[Andrew Morton <akpm@linux-foundation.org>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5311 bytes --]


The patch titled
     Subject: mm/list_lru: don't copy stale shrinker id from non-memcg-aware shrinkers
has been added to the -mm mm-new branch.  Its filename is
     mm-list_lru-dont-copy-stale-shrinker-id-from-non-memcg-aware-shrinkers.patch

This patch will shortly appear at
     https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-list_lru-dont-copy-stale-shrinker-id-from-non-memcg-aware-shrinkers.patch

This patch will later appear in the mm-new branch at
    git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

Note, mm-new is a provisional staging ground for work-in-progress
patches, and acceptance into mm-new is a notification for others take
notice and to finish up reviews.  Please do not hesitate to respond to
review feedback and post updated versions to replace or incrementally
fixup patches in mm-new.

The mm-new branch of mm.git is not included in linux-next

If a few days of testing in mm-new is successful, the patch will me moved
into mm.git's mm-unstable branch, which is included in linux-next

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***

The -mm tree is included into linux-next via various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days

------------------------------------------------------
From: Qinyun Tan <qinyuntan@linux.alibaba.com>
Subject: mm/list_lru: don't copy stale shrinker id from non-memcg-aware shrinkers
Date: Tue, 1 Sep 2026 19:51:04 +0800

With cgroup.memory=nokmem, shrinker_memcg_alloc() fails with -ENOSYS for
shrinkers without SHRINKER_NONSLAB, and shrinker_alloc() falls back to a
non-memcg-aware shrinker.  On this fallback path, shrinker->id is never
assigned and keeps 0 from kzalloc(), which is a valid id belonging to
whichever memcg-aware shrinker registers first.

__list_lru_init() copies shrinker->id unconditionally, so every list_lru
backed by such a fallback shrinker (thp-deferred_split, zswap-shrinker,
workingset shadow nodes, superblock lrus, ...) ends up with
lru->shrinker_id == 0 instead of -1.

Under nokmem the list_lru collapses to the shared per-node lists, but
__list_lru_add() still calls set_shrinker_bit() against the memcg of the
added object.  Most list_lru users are unaffected because their objects
resolve to a NULL memcg without kmem accounting, but the THP deferred
split queue holds user folios, which are charged regardless of nokmem. 
Since no memcg-aware shrinker can register under nokmem, shrinker_nr_max
stays 0 and every memcg's shrinker_info has map_nr_max == 0, so the first
folio added by khugepaged triggers on every boot:

  WARNING: mm/shrinker.c:212 at set_shrinker_bit+0x99/0xa0

On systems where a SHRINKER_NONSLAB shrinker (btrfs, xfs) did register and
expand the maps, there is no warning; instead bit 0 is set spuriously for
an unrelated shrinker.

shrinker->id is only meaningful while SHRINKER_MEMCG_AWARE is set, and all
readers inside mm/shrinker.c already check the flag before using the id. 
Make __list_lru_init() do the same and fall back to -1, so
set_shrinker_bit() is never reached with a bogus id.  The stale
shrinker->id itself is left as is; cleaning that up is a separate topic.

Verified on a machine booting with cgroup.memory=nokmem and
CONFIG_TRANSPARENT_HUGEPAGE=y: the warning fires once per boot from
khugepaged, disappears when nokmem is removed from the command line, and
no longer triggers with this fix applied and nokmem set.

Link: https://lore.kernel.org/20260901115104.2944996-1-qinyuntan@linux.alibaba.com
Fixes: 03375203e1da8 ("mm: do not allocate shrinker info with cgroup.memory=nokmem")
Signed-off-by: Qinyun Tan <qinyuntan@linux.alibaba.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: David Hildenbrand <david@kernel.org>
Cc: Lance Yang <lance.yang@linux.dev>
Cc: Michal Koutný <mkoutny@suse.com>
Cc: Xunlei Pang <xlpang@linux.alibaba.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/list_lru.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/mm/list_lru.c~mm-list_lru-dont-copy-stale-shrinker-id-from-non-memcg-aware-shrinkers
+++ a/mm/list_lru.c
@@ -666,7 +666,12 @@ int __list_lru_init(struct list_lru *lru
 	int i;
 
 #ifdef CONFIG_MEMCG
-	if (shrinker)
+	/*
+	 * If the shrinker fell back to being non-memcg-aware (e.g. with
+	 * cgroup.memory=nokmem), its id was never assigned and holds a
+	 * stale 0. Don't let set_shrinker_bit() act on it.
+	 */
+	if (shrinker && (shrinker->flags & SHRINKER_MEMCG_AWARE))
 		lru->shrinker_id = shrinker->id;
 	else
 		lru->shrinker_id = -1;
_

Patches currently in -mm which might be from qinyuntan@linux.alibaba.com are

mm-list_lru-dont-copy-stale-shrinker-id-from-non-memcg-aware-shrinkers.patch