make unused huge shrinker memcg aware

Commit 0ef8faff490be ("fs: push nr_cached_objects memcg gating into individual filesystems") forgot to drop the super_fs_objects_eligible(), just fix it.

Quoted 3 lines · On Mon, 3 Aug 2026 16:46:33 +0800 Qi Zheng <[email protected]> wrote:

Commit 0ef8faff490be ("fs: push nr_cached_objects memcg gating into individual filesystems") forgot to drop the super_fs_objects_eligible(), just fix it.

What are the userspace-visible runtime effects of this bug? Please include this info with all bugfix patches.

Should we cc:stable?

Thanks.

From: Qi Zheng <[email protected]>

The shmem_get_folio_gfp() adds the inode to the unused huge shrinker list at the alloced label, but a subsequent truncation check may still fail and remove the folio, leaving the inode on the list with a stale folio.

The original code works because the shrinker re-looks-up the folio and drops stale entries, but it is cleaner to queue the inode only after all checks that might remove the folio have passed.

So just make the pure structural move with no functional change, and it serves as preparation for the memcg-aware shrinker conversion.

Signed-off-by Qi Zheng <[email protected]>

From: Qi Zheng <[email protected]>

The shmem_get_folio_gfp() adds the inode to the unused huge shrinker list at the alloced label, but a subsequent truncation check may still fail and remove the folio, leaving the inode on the list with a stale folio.

The original code works because the shrinker re-looks-up the folio and drops stale entries, but it is cleaner to queue the inode only after all checks that might remove the folio have passed.

So just make the pure structural move with no functional change, and it serves as preparation for the memcg-aware shrinker conversion.

Signed-off-by Qi Zheng <[email protected]>

---

From: Qi Zheng <[email protected]>

The shmem unused huge shrinker keeps a per-superblock list of inodes whose tail huge folio extends beyond i_size. Since that list is not memcg aware, reclaim triggered by one memcg can scan inodes from the whole superblock and split shmem huge folios charged to unrelated memcgs.

Convert the shrink list to a memcg-aware list_lru. Queue each inode on the list_lru sublist matching the memcg and node of the current tail huge folio, so non-root memcg reclaim only walks candidates charged to the reclaiming memcg. Global reclaim, root memcg reclaim and shmem quota reclaim keep global semantics.

The list_lru still tracks inodes while the actual split target is the current tail huge folio, so validate the folio memcg/node during scan. If the folio no longer matches the reclaim context or splitting cannot proceed, requeue the inode according to the current tail folio; if the inode is no longer shrinkable, drop the scan entry.

This can be tested with the shrinker debugfs interface by allocating 32 tmpfs tail THPs in each of two memcgs, then scanning the sb-tmpfs shrinker with memcg A's cgroup id:

                before A scan    after A scan
   base         A=64M, B=64M     A=64M, B=64M (per-memcg count is skipped)
   patched      A=64M, B=64M     A=0,   B=64M

Signed-off-by Qi Zheng <[email protected]>

---

Quoted 23 lines · Qi Zheng

From: Qi Zheng <[email protected]>

The shmem unused huge shrinker keeps a per-superblock list of inodes whose tail huge folio extends beyond i_size. Since that list is not memcg aware, reclaim triggered by one memcg can scan inodes from the whole superblock and split shmem huge folios charged to unrelated memcgs.

Convert the shrink list to a memcg-aware list_lru. Queue each inode on the list_lru sublist matching the memcg and node of the current tail huge folio, so non-root memcg reclaim only walks candidates charged to the reclaiming memcg. Global reclaim, root memcg reclaim and shmem quota reclaim keep global semantics.

The list_lru still tracks inodes while the actual split target is the current tail huge folio, so validate the folio memcg/node during scan. If the folio no longer matches the reclaim context or splitting cannot proceed, requeue the inode according to the current tail folio; if the inode is no longer shrinkable, drop the scan entry.

This can be tested with the shrinker debugfs interface by allocating 32 tmpfs tail THPs in each of two memcgs, then scanning the sb-tmpfs shrinker with memcg A's cgroup id:

Quoted 6 lines

                before A scan    after A scan
   base         A=64M, B=64M     A=64M, B=64M (per-memcg count is skipped) patched      A=64M, B=64M     A=0,   B=64M

Signed-off-by Qi Zheng <[email protected]>

---

Apart from the two issues Sashiko pointed out (which you've already replied to), nothing else jumped out at me. Thanks.

From: Qi Zheng <[email protected]>

Quoted 1 line · Qi Zheng

From: Qi Zheng <[email protected]>

I'm missing description and motivation here.

This is only about shrinking huge pages that span end of shmem files.

Is this really a problem? And if so, why?

Quoted 1 line · On Mon, 3 Aug 2026 16:46:32 +0800 Qi Zheng <[email protected]> wrote:

What David said.

Also, AI review might have found a couple of things:

	https://sashiko.dev/#/patchset/[email protected]

Review

Quoted 10 lines

(quoted diff) +10 -0

+static struct mem_cgroup *
+shmem_unused_huge_alloc_lru(struct shmem_sb_info *sbinfo, struct folio *folio,
+			    gfp_t gfp)
+{
+	struct mem_cgroup *memcg;
+	int ret;
+
+	memcg = get_mem_cgroup_from_folio(folio);
+	if (!memcg)
+		return NULL;

Could this leak the mem_cgroup structure if a file is truncated?

When shmem_unused_huge_add() calls this function, it stores the memcg reference in info->shrinklist_memcg.
If an unprivileged user truncates the file to 0 bytes, shmem_truncate_range() frees the folio, but it does not remove the inode from the shrinklist or drop this memcg reference.
Without memory pressure to trigger the shrinker, the mem_cgroup might remain pinned indefinitely until the file is deleted, potentially allowing zombie memcgs to accumulate on the system.

[ ... ]

Quoted 17 lines

(quoted diff) +17 -0

+static bool is_shmem_unused_huge_match(struct folio *folio,
+				       struct shrink_control *sc)
+{
+	struct mem_cgroup *memcg = NULL;
+	bool match;
+
+	/*
+	 * Only non-root memcg reclaim needs to match the folio charge against
+	 * sc->memcg. Skip the folio memcg check for the following cases:
+	 * 1. shmem quota reclaim (sc == NULL)
+	 * 2. global shrinker reclaim
+	 * 3. root memcg reclaim
+	 */
+	if (!sc || !sc->memcg || mem_cgroup_is_root(sc->memcg))
+		return true;
+
+	if (folio_nid(folio) != sc->nid)

Review

Quoted 1 line

(quoted diff) +1 -0

+		return false;

Does this early return bypass the NUMA node check for global and root memcg reclaim?
The comment indicates this is only intended to skip the folio memcg check. However, returning true immediately also bypasses the sc->nid check. If a huge folio is migrated to a different NUMA node, kswapd or direct reclaim might incorrectly split folios on the wrong node instead of requeuing the inode to the correct node's list.