All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qi Zheng <qi.zheng@linux.dev>
To: Andrew Morton <akpm@linux-foundation.org>, baolin.wang@linux.alibaba.com
Cc: hughd@google.com, usama.arif@linux.dev, brauner@kernel.org,
	david@kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,
	Qi Zheng <zhengqi.arch@bytedance.com>
Subject: Re: [PATCH v3 0/3] make unused huge shrinker memcg aware
Date: Tue, 4 Aug 2026 14:36:58 +0800	[thread overview]
Message-ID: <5f8c068a-42a8-450a-aa49-febd8c7bd1e7@linux.dev> (raw)
In-Reply-To: <20260803142425.fd860e19e77a11ccc3c84439@linux-foundation.org>

Hi Andrew,

On 8/4/26 5:24 AM, Andrew Morton wrote:
> On Mon,  3 Aug 2026 16:46:32 +0800 Qi Zheng <qi.zheng@linux.dev> wrote:
> 
>>
> 
> What David said.
> 
> Also, AI review might have found a couple of things:
> 	https://sashiko.dev/#/patchset/cover.1785746588.git.zhengqi.arch@bytedance.com

I saw it, and it sounds reasonable.

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

Indeed, will also call shmem_unused_huge_del() in shmem_truncate_range()
to take the inode off the shrinklist in time.

 > [ ... ]
 > > +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)
 > > +		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.

Indeed, root memcg reclaim also needs to check if the nid matches.

Will move the nid check earlier in v4:

       if (!sc)
               return true;

       if (folio_nid(folio) != sc->nid)
               return false;

       if (!sc->memcg || mem_cgroup_is_root(sc->memcg))
               return true;

Thanks,
Qi





      reply	other threads:[~2026-08-04  6:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-03  8:46 [PATCH v3 0/3] make unused huge shrinker memcg aware Qi Zheng
2026-08-03  8:46 ` [PATCH v3 1/3] fs: fix missed removal of super_fs_objects_eligible() Qi Zheng
2026-08-03 21:20   ` Andrew Morton
2026-08-04  6:18     ` Qi Zheng
2026-08-03  8:46 ` [PATCH v3 2/3] mm: shmem: move unused huge shrinklist queuing past the truncation check Qi Zheng
2026-08-04  7:03   ` Qi Zheng
2026-08-05  3:20   ` Baolin Wang
2026-08-03  8:46 ` [PATCH v3 3/3] mm: shmem: make unused huge shrinker memcg aware Qi Zheng
2026-08-06  5:35   ` Baolin Wang
2026-08-06  6:10     ` Qi Zheng
2026-08-03 12:21 ` [PATCH v3 0/3] " David Hildenbrand (Arm)
2026-08-04  3:51   ` Qi Zheng
2026-08-03 21:24 ` Andrew Morton
2026-08-04  6:36   ` Qi Zheng [this message]

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=5f8c068a-42a8-450a-aa49-febd8c7bd1e7@linux.dev \
    --to=qi.zheng@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=brauner@kernel.org \
    --cc=david@kernel.org \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=usama.arif@linux.dev \
    --cc=zhengqi.arch@bytedance.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.