From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-179.mta1.migadu.com (out-179.mta1.migadu.com [95.215.58.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 237FB2931E6 for ; Tue, 4 Aug 2026 06:37:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785825459; cv=none; b=TWe2PAD7bJSC9b1ycjmEiId8Mk1IDnDZ7uaKXN8/G4w1SIWJ6gA5hv07RZSCkf/gZ//DWtedrjjJQzFQY42ybo06z+PfH1dtYgP6p3mi1dWLfYFy7GAIjSxrAcstjEHA6Pkedranxxn0hLlV5PtwNNhLZfjsX0zDYZexf8Zo65M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785825459; c=relaxed/simple; bh=fE8EiGZ/SlxBV6elNRXD/o+dX3hMghFCAlctnKtLK6s=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=RcQXPcM1YKYlH0bf+lqH0pQtB0k0+7+MePOTZi1ZATpSyfT+XwLuW52+X7sdpgLPTKHiifr/x4z1ROJv/Umj5PuOw1D5+vGTZdDQYmvnGYCFnpZ8EbclEk97vmlXv6lPp5fQabMBYz8bHbo/Zz40ouXSSTvPYp8MRL3WmgjU8yU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=PSWXFNso; arc=none smtp.client-ip=95.215.58.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="PSWXFNso" Message-ID: <5f8c068a-42a8-450a-aa49-febd8c7bd1e7@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1785825454; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jK4rT+meu5ARGYqbR8MMT84cChMLTkR3Mr4nGB3s4lA=; b=PSWXFNsoSj1ztq0UlItlSol7s4+HDqPmPiOLDojmN7VXbEPD6ZIxD9BZUbpMT/R0HI7M/F A4e1rFPcLi3odSVfVJuH2GYjnIvrjDHqTjLdIYpcfmy18FyK6v1sG0dR1w1cein+ojCDBb Pr4kjT3oimEqT5JBG/TV/CqSp5R7gU0= Date: Tue, 4 Aug 2026 14:36:58 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v3 0/3] make unused huge shrinker memcg aware To: Andrew Morton , 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 References: <20260803142425.fd860e19e77a11ccc3c84439@linux-foundation.org> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Qi Zheng In-Reply-To: <20260803142425.fd860e19e77a11ccc3c84439@linux-foundation.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT Hi Andrew, On 8/4/26 5:24 AM, Andrew Morton wrote: > On Mon, 3 Aug 2026 16:46:32 +0800 Qi Zheng 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