From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794046832; b=SpYC44YwgjSssXtypyn4h7on3ooZFQ1dCocVR5z0JirGtCWCbumyYjRJmYcI1lyfnswo YQvxaEyk2ffCwcDVp6aqODl49SMAxUEj0JjDOevLjQokm4jNgIN3Q+EfTnc895U+vfkpE Or5Ai7troI2ajqPr6+QwoneBDzLS+0NvAX0lXDa/NB3TZx1m120Y4IO3N5csQ7pQDA7j1 8bOgi1UQuqyUTNQFo6BWVjf8petJh7V5q++R1kAL+bcR0KxBu+W25hdVA0b3L3jDC+co1 Kv/wcSiiReaFXGNbSsYhvyRN8Q41f9yl+ELOVwWdhRp6CeqM+0KXtOOHSPFMYyiur3w== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794046832; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: MIME-Version:Content-Type:Content-Transfer-Encoding; bh=P/8+Qg/6tTpVCMKbCj+S3eki9U7BmsfdzbQN/WuAW5Q=; b=roG0UggamMTh3wS6N37dZ0xf3zQqxNCY4tHdNIjepIgXyKdVABj3NY21u9WdWrW/wcoG F3L+ageXH0kupsha+TmQdtrieDk83LAyNyt2z0gmOzPVjL+wd5JV71fkICjapdZi44KUn nYYfa5aLjc9FkuSIUEw8KepFEaNG0uI2St3WqKDR8QK9db5zC542x+J5L3CcABZqhwhdM 3gI4dSxx7afSq6MPeuEeQiHhli0uAmNPnQzuDYUmJAUyMs8IrwETgJyhu0Ate32wKqhVq KRtmKXtcrBGoOTsPqsFE+TOzortJSmOaJ2pdwD/v/lzm/D8pdJwscceucsgakpmHarQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=EGEPQxUF; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1AB94606A33E for ; Sat, 7 Nov 2026 10:20:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=EGEPQxUF Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3884D1F008A1; Sat, 7 Nov 2026 10:20:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794046832; bh=P/8+Qg/6tTpVCMKbCj+S3eki9U7BmsfdzbQN/WuAW5Q=; h=From:To:Cc:Subject:Date; b=EGEPQxUFUyopM8MHfxOMhN/iS/8W4DtJFIovlQhShmPRvLxqhdiaVc4OxJ6e3WURy gqowaQW532ZDE+q1c8L5Mwk28D+gXFwYx3LJ/EWnzie1VVAQidvdzS5uN1JYTN2yS/ CG6ZTSOdIxt8bqHnl71Wmf8hM1DzvIw70rUq+xt0H1AtErWnAHtY4DUX5dHHVnhSgo ert1MypqFd8/j8MU7RhBSnOI815M+2jkIOU6dV4Iku00fVC+cw/J410d7S239gRwzD 1yC+F7CUmSfCF2WcVZfa1dTIIrxNfpgtybM+Hirtcbx8Bgfu8rvzMuiKONcfOyMBVg nQyEVOYoLKyNA== From: Sasha Levin To: chenridong@xiaomi.com, baohua@kernel.org, hannes@cmpxchg.org, akpm@linux-foundation.org, axelrasmussen@google.com, chris@chrisdown.name, david@kernel.org, kasong@tencent.com, ljs@kernel.org, mhocko@kernel.org, muchun.song@linux.dev, roman.gushchin@linux.dev, shakeel.butt@linux.dev, tj@kernel.org, weixugc@google.com, yuanchu@google.com, yuzhao@google.com Cc: stable@vger.kernel.org Subject: FAILED: patch "[PATCH] mm/page_counter: avoid integer overflow in effective_protection()" failed to apply to 6.12-stable tree Date: Sat, 7 Nov 2026 05:20:29 -0500 Message-ID: <20261107052029-failed-6.12-7809ce47b056@kernel.org> X-Mailer: git-send-email 2.53.0 X-Mailing-List: stable@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x 7809ce47b05671e1fa6d74bead892d6ad6c1403b # git commit -s git send-email --to '' --in-reply-to '20261107052029-failed-6.12-7809ce47b056@kernel.org' --subject-prefix 'PATCH 6.12.y' 'HEAD^..' Thanks, Sasha ------------------ original commit in Linus's tree ------------------ >From 7809ce47b05671e1fa6d74bead892d6ad6c1403b Mon Sep 17 00:00:00 2001 From: Ridong Chen Date: Mon, 7 Sep 2026 10:54:44 +0800 Subject: [PATCH] mm/page_counter: avoid integer overflow in effective_protection() Patch series "mm/mglru: fix ineffective memory protection for non-kswapd reclaim", v4. For MGLRU, memory.min/low is not honored during non-kswapd global reclaim (global direct reclaim and root-level memory.reclaim), because these paths shrink memcgs using stale protection (emin/elow). Patch 2 is the actual fix. Patch 1 is a prerequisite: an integer overflow in effective_protection(), spotted by the sashiko review tool, which patch 2's new caller would also be exposed to. This patch (of 2): 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 >= 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 <= 1. Reported by the sashiko review tool [1]. Link: https://lore.kernel.org/20260907025445.1836238-1-ridong.chen@linux.dev Link: https://lore.kernel.org/20260907025445.1836238-2-ridong.chen@linux.dev Link: https://sashiko.dev/#/patchset/20260826133054.88529-1-ridong.chen@linux.dev?part=1 [1] Fixes: bc50bcc6e00b ("mm: memcontrol: clean up and document effective low/min calculations") Fixes: 8a931f801340 ("mm: memcontrol: recursive memory.low protection") Reviewed-by: Barry Song Reviewed-by: Johannes Weiner Signed-off-by: Ridong Chen Signed-off-by: Andrew Morton Assisted-by: Claude:claude-opus-4-8 Cc: Axel Rasmussen Cc: Chris Down Cc: David Hildenbrand Cc: Kairui Song Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Shakeel Butt Cc: Tejun Heo Cc: Wei Xu Cc: Yuanchu Xie Cc: Yu Zhao Cc: --- mm/page_counter.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/mm/page_counter.c b/mm/page_counter.c index 450543f4b318b..98322803941a7 100644 --- a/mm/page_counter.c +++ b/mm/page_counter.c @@ -8,6 +8,7 @@ #include #include #include +#include #include #include #include @@ -376,7 +377,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); /* * Ok, utilized protection of all children is within what the @@ -417,13 +419,20 @@ static unsigned long effective_protection(unsigned long usage, if (parent_effective > siblings_protected && parent_usage > siblings_protected && usage > protected) { - unsigned long unclaimed; + unsigned long parent_unclaimed, parent_unprotected, unprotected; - unclaimed = parent_effective - siblings_protected; - unclaimed *= usage - protected; - unclaimed /= parent_usage - siblings_protected; + parent_unclaimed = parent_effective - siblings_protected; + parent_unprotected = parent_usage - siblings_protected; - ep += unclaimed; + /* + * 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 = min(usage - protected, parent_unprotected); + + ep += mul_u64_u64_div_u64(parent_unclaimed, unprotected, + parent_unprotected); } return ep; -- 2.53.0