From nobody Sat Sep 26 08:37:12 2026 Received: from mta1.migadu.com (out-208.mta1.migadu.com [95.215.58.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EF91736167E for ; Thu, 3 Sep 2026 03:20:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.208 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788405645; cv=none; b=FObE9isR4Nx5BblOqR+MXwMELapXUVc5M9hQbyS9rqYV2fJn9f8ekDF7mhk1Z9/turNP9fRwxb7BISCZIxatFFWZ+b3CbsLNyMgCv5Fv2NAOebtPqeXaCcNcUqSqZcjawJLliYgKJxgVMwhx/n5X/fZ2WVP1kcOtva9sOEDJlV4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788405645; c=relaxed/simple; bh=fEx4cyQIe7jbrV6zti+QPYuHP8t/WPfzOFNbVO2zmy4=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=pm6+EHnpVvhwqwb1YqfvFTcPscsj88w/hRfKVt2MJ3vdMoVpDXdPP+3WrPNkrAXvgZLtadwGmkN1OPyAiRY61XMFB+ZrXXIH6f7cyevn6hj4u+KGtlX6+iIMh8xfIu3EN+mBtH7kXM+cC6pi8fYfEIDWo/fmZU3FLmdws/2FRcg= 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=Nwy9m+3F; arc=none smtp.client-ip=95.215.58.208 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="Nwy9m+3F" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=fEx4cyQIe7jbrV6zti+QPYuHP8t/WPfzOFNbVO2zmy4=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1788405641; v=1; x=1789010441; b=Nwy9m+3Fu0pF46evUpenRZPGoNHxzzoB716o49bnng/0oAZZn3eOOMDskOeJhoLWz43xjEkf o3VTUePWINOZSN8wqxi27J5p02XF43nTdUOMteKQ9dWL/cl/qTnkwRPtZT5v0h4oq6xTPFb9FUW G/LWM1soUgyNRdLnBQeC5iow= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 530d96b07d063574; Thu, 03 Sep 2026 03:20:41 +0000 X-Mizu-Trace-ID: 530d96b07d063574 X-Migadu-Flow: FLOW_OUT From: Ridong Chen To: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Andrew Morton Cc: Muchun Song , Kairui Song , Qi Zheng , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , David Hildenbrand , Lorenzo Stoakes , Chris Down , Tejun Heo , Yu Zhao , cgroups@vger.kernel.org (open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)), linux-mm@kvack.org (open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)), linux-kernel@vger.kernel.org, Ridong Chen , Ridong Chen , stable@vger.kernel.org Subject: [PATCH v3 1/2] mm/page_counter: avoid integer overflow in effective_protection() Date: Thu, 3 Sep 2026 11:19:51 +0800 Message-Id: <20260903031952.1120321-2-ridong.chen@linux.dev> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260903031952.1120321-1-ridong.chen@linux.dev> References: <20260903031952.1120321-1-ridong.chen@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ridong Chen effective_protection() scales a parent's protection by a ratio of page counts, e.g. for recursive protection: (parent_effective - siblings_protected) * (usage - protected) / (parent_usage - siblings_protected) The multiply is done at unsigned long width before dividing. On systems with >=3D 16TB RAM the product can exceed 2^64 and wrap, giving a bogus protection value and silently breaking memory.min/low enforcement. Use mul_u64_u64_div_u64() to multiply in a 128-bit intermediate. Because usage and parent_usage are not read atomically (a child is charged before its parent), usage - protected can briefly exceed the divisor, making the quotient overflow 64 bits and trap (#DE on x86). Cap it so the ratio stays <=3D 1. Reported by the sashiko review tool [1]. [1] https://sashiko.dev/#/patchset/20260826133054.88529-1-ridong.chen@linux= .dev?part=3D1 Fixes: bc50bcc6e00b ("mm: memcontrol: clean up and document effective low/m= in calculations") Fixes: 8a931f801340 ("mm: memcontrol: recursive memory.low protection") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Barry Song Signed-off-by: Ridong Chen Reviewed-by: Johannes Weiner --- mm/page_counter.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/mm/page_counter.c b/mm/page_counter.c index 661e0f2a5127..e8bd512069c5 100644 --- a/mm/page_counter.c +++ b/mm/page_counter.c @@ -8,6 +8,7 @@ #include #include #include +#include #include #include #include @@ -356,7 +357,8 @@ static unsigned long effective_protection(unsigned long= usage, * otherwise get a smaller chunk than what they claimed. */ if (siblings_protected > parent_effective) - return protected * parent_effective / siblings_protected; + return mul_u64_u64_div_u64(protected, parent_effective, + siblings_protected); =20 /* * Ok, utilized protection of all children is within what the @@ -397,13 +399,18 @@ static unsigned long effective_protection(unsigned lo= ng usage, if (parent_effective > siblings_protected && parent_usage > siblings_protected && usage > protected) { - unsigned long unclaimed; + unsigned long unclaimed =3D parent_effective - siblings_protected; + unsigned long unprotected =3D usage - protected; + unsigned long parent_unprotected =3D parent_usage - siblings_protected; =20 - unclaimed =3D parent_effective - siblings_protected; - unclaimed *=3D usage - protected; - unclaimed /=3D parent_usage - siblings_protected; + /* + * The usages aren't read atomically, so a child can transiently + * appear to use more than its parent, making the ratio exceed 1 + * and the quotient overflow 64 bits (#DE on x86). Cap it. + */ + unprotected =3D min(unprotected, parent_unprotected); =20 - ep +=3D unclaimed; + ep +=3D mul_u64_u64_div_u64(unclaimed, unprotected, parent_unprotected); } =20 return ep; --=20 2.34.1 From nobody Sat Sep 26 08:37:12 2026 Received: from mta1.migadu.com (out-222.mta1.migadu.com [95.215.58.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 422062E7F20 for ; Thu, 3 Sep 2026 03:20:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.222 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788405652; cv=none; b=Enboqs/UCwJAVngXlODdsMD3nW4Sac8fC4fRvgM/HwssVWGmfvrMut3z8JC5Q4Xvwf7t8DC1BcCQ8QD+tsMA/Ho+8ovSC4ouBAwo1BP9GiuxmOjCOP6qx4lMqAObKKkuWccSLd56i5mRnl3p8F4mXheoVap4AWkoz3XzZ4Z41lo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788405652; c=relaxed/simple; bh=gV2iAlnyroIqHvYCikGMSiDdJzetMM/dbS3MYN3DzYc=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=pRUhN1dw4UE+4Q5HrD8okX0dBmzd55qie6ZGD57KmQ/zjf94ZdJcPAp4pVPdPJsYTD5sYscA+y4xVvGtAAP4iNWqlfQxQR227+m6hmgAryzhtm5/XTNgHOGGPvMuJXx5R0aY3SpDEExf4SM2HGtylQI/VlL4aaoorUDyrZIbcXw= 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=j76dF2sJ; arc=none smtp.client-ip=95.215.58.222 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="j76dF2sJ" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=gV2iAlnyroIqHvYCikGMSiDdJzetMM/dbS3MYN3DzYc=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1788405648; v=1; x=1789010448; b=j76dF2sJAXKSqCq3t+oFQZwG7Vrk+zPxk+JPRNrYlblKR2bv4gZ4O223kIWkUAVr+wUNIu+9 niu7mT+ZCGCAMhN3gtaD682/95Ms7OjFpdTAClFH2TZvz4aR7BQB0uuV9hWXDinGdHEvAiZAg3B Vg3aIyEn0a0S8pOBPU8bNRC0= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 0f653951e6c46c55; Thu, 03 Sep 2026 03:20:48 +0000 X-Mizu-Trace-ID: 0f653951e6c46c55 X-Migadu-Flow: FLOW_OUT From: Ridong Chen To: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Andrew Morton Cc: Muchun Song , Kairui Song , Qi Zheng , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , David Hildenbrand , Lorenzo Stoakes , Chris Down , Tejun Heo , Yu Zhao , cgroups@vger.kernel.org (open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)), linux-mm@kvack.org (open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)), linux-kernel@vger.kernel.org, Ridong Chen , Ridong Chen , stable@vger.kernel.org Subject: [PATCH v3 2/2] mm/mglru: fix ineffective memory protection for non-kswapd reclaim Date: Thu, 3 Sep 2026 11:19:52 +0800 Message-Id: <20260903031952.1120321-3-ridong.chen@linux.dev> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260903031952.1120321-1-ridong.chen@linux.dev> References: <20260903031952.1120321-1-ridong.chen@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ridong Chen For MGLRU, memory.min/low is not honored during global proactive reclaim (writing to the root memory.reclaim) and global direct reclaim, because these paths shrink memcgs using stale or effective protection (emin/elow). It can be reproduced as follows: # echo 7 > /sys/kernel/mm/lru_gen/enabled # cd /sys/fs/cgroup # mkdir -p a/b # echo 100M > a/memory.min # echo +memory > a/cgroup.subtree_control # echo 100M > a/b/memory.min # echo $$ > a/b/cgroup.procs # dd if=3D/dev/zero of=3D/tmp/testfile bs=3D1M count=3D200 # cat a/b/memory.current 222650368 # echo 500M > memory.reclaim -bash: echo: write error: Resource temporarily unavailable # cat a/b/memory.current 6070272 memory.min is 100M, yet reclaim drops a/b down to 6M, breaking the protection. The traditional LRU path is not affected because shrink_node() calls mem_cgroup_calculate_protection() for each memcg it visits during a top-down tree walk. Commit 30d77b7eef01 ("mm/mglru: fix ineffective protection calculation") moved the protection computation into lru_gen_age_node(), which only runs for kswapd. Non-kswapd global reclaim reaches shrink_one() through lru_gen_shrink_node() -> shrink_many() without any protection computation, so emin/elow are whatever a previous kswapd run left behind - or zero if kswapd never ran on this node. Relying on a prior kswapd pass is not correct either: a memcg's emin/elow are derived from its ancestors' memory.min/low settings and from children_min_usage, both of which change over time, so emin/elow go stale even after kswapd has run and must be recomputed at the point of reclaim. Introduce mem_cgroup_calculate_protection_path() which computes emin/elow along the root-to-target path only, by iterating through the cgroup ancestors array top-down. This avoids the full tree traversal that would be needed with mem_cgroup_calculate_protection(), limiting the cost to O(depth) per memcg - typically 3-5 levels. Call it from shrink_one() for the non-kswapd path so that each memcg about to be shrunk has correct protection values. Fixes: e4dde56cd208 ("mm: multi-gen LRU: per-node lru_gen_folio lists") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Ridong Chen Reviewed-by: Barry Song Reviewed-by: Johannes Weiner --- include/linux/memcontrol.h | 10 +++++++++ mm/memcontrol.c | 45 ++++++++++++++++++++++++++++++++++++++ mm/vmscan.c | 8 ++++++- 3 files changed, 62 insertions(+), 1 deletion(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index f227348a3f24..a65a516adc66 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -1885,6 +1885,16 @@ static inline bool memcg_is_dying(struct mem_cgroup = *memcg) } #endif /* CONFIG_MEMCG */ =20 +#if defined(CONFIG_MEMCG) && defined(CONFIG_LRU_GEN) +void mem_cgroup_calculate_protection_path(struct mem_cgroup *root, + struct mem_cgroup *memcg); +#else +static inline void mem_cgroup_calculate_protection_path(struct mem_cgroup = *root, + struct mem_cgroup *memcg) +{ +} +#endif + #if defined(CONFIG_MEMCG) && defined(CONFIG_ZSWAP) bool obj_cgroup_may_zswap(struct obj_cgroup *objcg); void obj_cgroup_charge_zswap(struct obj_cgroup *objcg, size_t size); diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 256b68ffca70..ae568fc68813 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -5214,6 +5214,51 @@ void mem_cgroup_calculate_protection(struct mem_cgro= up *root, page_counter_calculate_protection(&root->memory, &memcg->memory, recursiv= e_protection); } =20 +#ifdef CONFIG_LRU_GEN +/** + * mem_cgroup_calculate_protection_path - compute protection along a path + * @root: the top ancestor of the sub-tree being checked (NULL for root_me= m_cgroup) + * @memcg: the target memory cgroup + * + * Walk the ancestor path from @root down to @memcg and compute the effect= ive + * protection at each level. This is safe for isolated queries because it + * ensures parents are computed before children. + */ +void mem_cgroup_calculate_protection_path(struct mem_cgroup *root, + struct mem_cgroup *memcg) +{ + bool recursive_protection =3D + cgrp_dfl_root.flags & CGRP_ROOT_MEMORY_RECURSIVE_PROT; + struct cgroup *cg; + int root_level, i; + + if (mem_cgroup_disabled()) + return; + + if (!root) + root =3D root_mem_cgroup; + + if (memcg =3D=3D root) + return; + + root_level =3D root->css.cgroup->level; + cg =3D memcg->css.cgroup; + + rcu_read_lock(); + for (i =3D root_level + 1; i <=3D cg->level; i++) { + struct mem_cgroup *cur; + + cur =3D mem_cgroup_from_css(cgroup_css(cg->ancestors[i], + &memory_cgrp_subsys)); + if (cur) + page_counter_calculate_protection(&root->memory, + &cur->memory, + recursive_protection); + } + rcu_read_unlock(); +} +#endif /* CONFIG_LRU_GEN */ + static int charge_memcg(struct folio *folio, struct mem_cgroup *memcg, gfp_t gfp) { diff --git a/mm/vmscan.c b/mm/vmscan.c index b4c9b8f3dfe9..500cc2051d13 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -5111,7 +5111,13 @@ static int shrink_one(struct lruvec *lruvec, struct = scan_control *sc) struct mem_cgroup *memcg =3D lruvec_memcg(lruvec); struct pglist_data *pgdat =3D lruvec_pgdat(lruvec); =20 - /* lru_gen_age_node() called mem_cgroup_calculate_protection() */ + /* + * For kswapd, lru_gen_age_node() has already called + * mem_cgroup_calculate_protection() + */ + if (!current_is_kswapd()) + mem_cgroup_calculate_protection_path(NULL, memcg); + if (mem_cgroup_below_min(NULL, memcg)) return MEMCG_LRU_YOUNG; =20 --=20 2.34.1