From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org,xlpang@linux.alibaba.com,stable@vger.kernel.org,shakeel.butt@linux.dev,roman.gushchin@linux.dev,muchun.song@linux.dev,mkoutny@suse.com,mhocko@suse.com,lance.yang@linux.dev,hannes@cmpxchg.org,guanwentao@uniontech.com,david@kernel.org,david@fromorbit.com,baolin.wang@linux.alibaba.com,qinyuntan@linux.alibaba.com,akpm@linux-foundation.org
Subject: [merged mm-stable] mm-list_lru-dont-copy-stale-shrinker-id-from-non-memcg-aware-shrinkers.patch removed from -mm tree
Date: Tue, 06 Oct 2026 17:52:33 -0700 [thread overview]
Message-ID: <20261007005234.5B8881F0089D@smtp.kernel.org> (raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4242 bytes --]
The quilt patch titled
Subject: mm/list_lru: don't copy stale shrinker id from non-memcg-aware shrinkers
has been removed from the -mm tree. Its filename was
mm-list_lru-dont-copy-stale-shrinker-id-from-non-memcg-aware-shrinkers.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: 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. On a system where no SHRINKER_NONSLAB shrinker registers,
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: fafaeceb89a5e ("mm: switch deferred split shrinker to list_lru")
Signed-off-by: Qinyun Tan <qinyuntan@linux.alibaba.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Muchun Song <muchun.song@linux.dev>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Reported-by: Wentao Guan <guanwentao@uniontech.com>
Closes: https://lore.kernel.org/linux-mm/20260904190028.21542-1-guanwentao@uniontech.com/
Tested-by: Wentao Guan <guanwentao@uniontech.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: 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>
---
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
reply other threads:[~2026-10-07 0:52 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=20261007005234.5B8881F0089D@smtp.kernel.org \
--to=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@fromorbit.com \
--cc=david@kernel.org \
--cc=guanwentao@uniontech.com \
--cc=hannes@cmpxchg.org \
--cc=lance.yang@linux.dev \
--cc=mhocko@suse.com \
--cc=mkoutny@suse.com \
--cc=mm-commits@vger.kernel.org \
--cc=muchun.song@linux.dev \
--cc=qinyuntan@linux.alibaba.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=stable@vger.kernel.org \
--cc=xlpang@linux.alibaba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.