[PATCH] mm/list_lru: don't copy stale shrinker id from non-memcg-aware shrinkers

[PATCH] mm/list_lru: don't copy stale shrinker id from non-memcg-aware shrinkers

[Qinyun Tan]

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.

Fixes: 03375203e1da8 ("mm: do not allocate shrinker info with cgroup.memory=nokmem")
Signed-off-by: Qinyun Tan <qinyuntan@linux.alibaba.com>
---

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.

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

diff --git a/mm/list_lru.c b/mm/list_lru.c
index 36662d02ff963..96d02ea206a88 100644
--- a/mm/list_lru.c
+++ b/mm/list_lru.c
@@ -666,7 +666,12 @@ int __list_lru_init(struct list_lru *lru, bool memcg_aware, struct shrinker *shr
 	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;
-- 
2.43.7

Re: [PATCH] mm/list_lru: don't copy stale shrinker id from non-memcg-aware shrinkers

[Andrew Morton]

On Tue,  1 Sep 2026 19:51:04 +0800 Qinyun Tan <qinyuntan@linux.alibaba.com> wrote:

> 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.

Thanks.  I'll queue this for test and review.

> Fixes: 03375203e1da8 ("mm: do not allocate shrinker info with cgroup.memory=nokmem")

Worth a cc:stable, I assume.

> ---
> 
> 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.

That's useful info.  I'll move it into the changelog.


Sashiko thinks there's a problem with cgroup_disable=memory as well:
	https://sashiko.dev/#/patchset/20260901115104.2944996-1-qinyuntan@linux.alibaba.com

Re: [PATCH] mm/list_lru: don't copy stale shrinker id from non-memcg-aware shrinkers

[Qinyun Tan]

Hi,

On 9/2/26 1:29 AM, Andrew Morton wrote:
> On Tue,  1 Sep 2026 19:51:04 +0800 Qinyun Tan <qinyuntan@linux.alibaba.com> wrote:
> 
>> 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.
> 
> Thanks.  I'll queue this for test and review.
> 
>> Fixes: 03375203e1da8 ("mm: do not allocate shrinker info with cgroup.memory=nokmem")
> 
> Worth a cc:stable, I assume.
> 
>> ---
>>
>> 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.
> 
> That's useful info.  I'll move it into the changelog.
> 
> 
> Sashiko thinks there's a problem with cgroup_disable=memory as well:
> 	https://sashiko.dev/#/patchset/20260901115104.2944996-1-qinyuntan@linux.alibaba.com

Yes, the observation is valid, and it turned out to be a real crash
on mm-new, not just a semantic inconsistency.

__list_lru_init() only checks mem_cgroup_kmem_disabled(), which
covers cgroup.memory=nokmem but not cgroup_disable=memory.  With the
controller disabled entirely, the lru stays memcg aware while
folio_memcg() is always NULL.

On mainline this is unreachable: the only caller of
folio_memcg_list_lru_alloc(), folio_memcg_alloc_deferred(), bails out
on mem_cgroup_disabled() first.  But the shmem unused-huge shrinker
conversion in mm-new ("mm: shmem: make unused huge shrinker memcg
aware") calls folio_memcg_list_lru_alloc() without such a guard, so
booting with cgroup_disable=memory and writing to a huge=always tmpfs
oopses immediately:

  BUG: unable to handle page fault for address: 0000000000000488
  RIP: 0010:folio_memcg_list_lru_alloc+0x41/0xf0
  Call Trace:
   shmem_get_folio_gfp+0x1cd/0x7c0
   shmem_write_begin+0x5d/0x100
   generic_perform_write+0x89/0x2a0
   shmem_file_write_iter+0x82/0x90
   vfs_write+0x256/0x410
   ksys_write+0x61/0xe0

The faulting address is the offset of mem_cgroup->kmemcg_id,
dereferenced on the NULL memcg in memcg_list_lru_allocated().

I've verified that checking mem_cgroup_disabled() in
__list_lru_init() fixes this: with the lru collapsed to plain
per-node lists, folio_memcg_list_lru_alloc() returns early, the
inode is queued on the per-node list with a NULL objcg (which the
shmem code and obj_cgroup_memcg() handle fine), and the shrinker
still reclaims via the global scan.  Same reproducer runs cleanly.

I'll send the fix as a follow-up patch shortly.  Since the
triggering commit is only in mm-new, no stable backport is needed;
it may make sense to keep it ahead of (or folded near) the shmem
series.

Thanks,
Qinyun Tan

Re: [PATCH] mm/list_lru: don't copy stale shrinker id from non-memcg-aware shrinkers

[Muchun Song]

> On Sep 1, 2026, at 19:51, Qinyun Tan <qinyuntan@linux.alibaba.com> wrote:
> 
> 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.
> 
> Fixes: 03375203e1da8 ("mm: do not allocate shrinker info with cgroup.memory=nokmem")
> Signed-off-by: Qinyun Tan <qinyuntan@linux.alibaba.com>

Acked-by: Muchun Song <muchun.song@linux.dev>

Thanks.

Re: [PATCH] mm/list_lru: don't copy stale shrinker id from non-memcg-aware shrinkers

[Baolin Wang]

On 9/1/26 7:51 PM, Qinyun Tan wrote:
> 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.
> 
> Fixes: 03375203e1da8 ("mm: do not allocate shrinker info with cgroup.memory=nokmem")
> Signed-off-by: Qinyun Tan <qinyuntan@linux.alibaba.com>
> ---

LGTM.
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>

Re: [PATCH] mm/list_lru: don't copy stale shrinker id from non-memcg-aware shrinkers

[Michal Koutný]

[-- Attachment #1: Type: text/plain, Size: 2233 bytes --]

Hello Qinyun.

On Tue, Sep 01, 2026 at 07:51:04PM +0800, Qinyun Tan <qinyuntan@linux.alibaba.com> wrote:
> 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.

<del>thp-deferred_split shrinek has SHRINKER_NONSLAB so, the id should be
assigned (at least I see it in thp_shrinker_init()).</del> I was looking
at 6.12 kernel.

> 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,

Not sure I understand here, the SHRINKER_NONSLAB are excluded and should
still register for per-memcg info.

> 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.

Could it be that you see this issue because of a shrinker which isn't
marked as SHRINKER_NONSLAB?

I'd even go as far as pointing at
fafaeceb89a5e ("mm: switch deferred split shrinker to list_lru")
which removed the flag from the the thp-deferred_split shrinker.

IOW, the proper fix should be addition of SHRINKER_NONSLAB so that
per-memcg maps are properly allocated.

Thanks,
Michal

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]

Re: [PATCH] mm/list_lru: don't copy stale shrinker id from non-memcg-aware shrinkers

[Qinyun Tan]

Hi Michal,

On 9/3/26 1:17 AM, Michal Koutný wrote:
> Hello Qinyun.
> 
> On Tue, Sep 01, 2026 at 07:51:04PM +0800, Qinyun Tan <qinyuntan@linux.alibaba.com> wrote:
>> 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.
> 
> <del>thp-deferred_split shrinek has SHRINKER_NONSLAB so, the id should be
> assigned (at least I see it in thp_shrinker_init()).</del> I was looking
> at 6.12 kernel.
> 
>> 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,
> 
> Not sure I understand here, the SHRINKER_NONSLAB are excluded and should
> still register for per-memcg info.
>
You're right, that sentence is imprecise - SHRINKER_NONSLAB shrinkers
do register per-memcg under nokmem.  What I meant is that on a system
where no NONSLAB shrinker happens to register, shrinker_nr_max stays 0.

>> 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.
> 
> Could it be that you see this issue because of a shrinker which isn't
> marked as SHRINKER_NONSLAB?
> 
> I'd even go as far as pointing at
> fafaeceb89a5e ("mm: switch deferred split shrinker to list_lru")
> which removed the flag from the the thp-deferred_split shrinker.
> 
> IOW, the proper fix should be addition of SHRINKER_NONSLAB so that
> per-memcg maps are properly allocated.
> 
> Thanks,
> Michal

Yes, good catch.  The flag was originally introduced for this very
shrinker by 0a432dcbeb32 ("mm: shrinker: make shrinker not depend on
memcg kmem"), and your 03375203e1da8 changelog even cites
deferred_split_shrinker as the NONSLAB example that still needs
per-memcg data.  fafaeceb89a5e dropped the flag without mentioning it
in the changelog, so this looks like an unintended loss.

That said, I see the flag restoration and this patch as complementary
rather than either-or: other MEMCG_AWARE-but-not-NONSLAB shrinkers
(superblock, workingset shadow nodes) still take the fallback path
under nokmem by design, and __list_lru_init() copying an unassigned
id there is a landmine independent of the deferred split case.  So I
think this patch is still wanted as the generic fix, with the flag
restoration on top for THP.

(zswap might deserve the same NONSLAB treatment as THP, btw - its
entries resolve the memcg from the folio's objcg, which is available
regardless of nokmem.)

Would you like me to send a separate patch restoring SHRINKER_NONSLAB
in thp_shrinker_init() (Fixes: fafaeceb89a5e)?  Happy to do so if
that works for you.

Andrew, since the patch is already in mm-new, could you please update
this changelog sentence

	"Since no memcg-aware shrinker can register under nokmem,"
to
	"On a system where no SHRINKER_NONSLAB shrinker registers,"

per Michal's comment above?  Or I can send a v2 if you prefer.

Thanks,
Qinyun Tan