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=1794050407; b=GddYRpQvM0rOvElhUnkdHglm9w7YQEf/vpjs6aDwYD4CVpiWUmqbXIbJXbpFsuERMMvZ xXRXOhpwEZsFs0TinzP9xDZ8R7Jw3UCPWb4oHp0x6Qk6E+qvDendreq/mGRTgUn2nxBD0 abaq+opNTJNOdctrsGbtO3NvW3SBQJxsBVKu+c5TlQBWZol+quhnYNzDiIhQSK8jrlI1C vTaVcmQsyAk2R9d/JeiLjs0aYoJuzv65KqadEOExSU7rOss7ckJYsdF/Nbch9UiZELH/n 61BEDpbwbMlFbsAZOCFVs9cZdmN/aSuvK8WYyZRne0EJ/EOd8XgPDNutlwr/eF+ehHw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794050407; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: MIME-Version:Content-Type:Content-Transfer-Encoding; bh=nfFIGidmhEnSlixcrZP/6ZTjJffyVN108QeGRK/9vkI=; b=skCx6UiQqrF+jITzFUW9S8073u2jrrCZY3Ei0CJL7MbcuVPvZ2yZPXZQxdeei7DKG2Bb FX3VR3wcTJJaLeIxeDSPbzedMT1lOWcpKY8dQpK42WRIqOO6bZWe33CFgJCPZLzAWHaop JkxBSuya7uzPemTW3VLgppbf0Hb/uRDg3dk5Jfy9IrZGm0Mh+SrxOjSc+PENdt58v3lOV ktmRbeHHNLIIWpmjW5dJnIWzR8b8IMB6S5/lmWlM19NtOf/PlqtijfFaKri7ismeEVnQj hkyL9qSpmcU/BkadvRt4vN9z3VZouumTZ9LERKvEYS5Jf607BDmEKmoJjKtOWLDX5cw== 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=i9XUXVYt; 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 B66F0606A326 for ; Sat, 7 Nov 2026 11:20:06 +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=i9XUXVYt Received: by smtp.kernel.org (Postfix) with ESMTPSA id 842171F0089F; Sat, 7 Nov 2026 11:20:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794050406; bh=nfFIGidmhEnSlixcrZP/6ZTjJffyVN108QeGRK/9vkI=; h=From:To:Cc:Subject:Date; b=i9XUXVYtWK0QvN26npZXtuWHipzh4LuU3E4HyRqnnbFxpDl9Zr0gWo5gV+nkrgr7p xjoCyH6wPvn7ilQpMYXsJhJ2/lxxvt7DWOoG64y5EJABCJ0AeaaBt2bJ+AP5U+u7EV BnG+7HQMZPSI204WBJAr0McDl6sfS7sa5QRDDy7tfjhQyy/RcBE0JZY9/fsqqsqlUx mJoITAXKi+Yd/QxFf+zle65iLfJOqOa8EMqBC2tgUfEl6Bfr+9jUiu/bvlOTbJPMPZ OodjG2shorrmUP1x6MqpinBwlhoTxjqUhsRAuTOn82kg3tAY631LBdOhBnxCO9Vkof GTZ9xQswKO4nQ== 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 5.10-stable tree Date: Sat, 7 Nov 2026 06:20:03 -0500 Message-ID: <20261107062002-failed-5.10-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 5.10-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-5.10.y git checkout FETCH_HEAD git cherry-pick -x 7809ce47b05671e1fa6d74bead892d6ad6c1403b # git commit -s git send-email --to '' --in-reply-to '20261107062002-failed-5.10-7809ce47b056@kernel.org' --subject-prefix 'PATCH 5.10.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