From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 D586E1DE8AF for ; Wed, 25 Mar 2026 23:57:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774483037; cv=none; b=LBHLeBwBvwnAaZ//tD9TakWFhYFTLVElGM5l4z/sz/tnzgBMng5Xag43UxOWH6W1Va237OEcgfk9Ie93+irgZabzKYKpGj9/2qM6vzSOBuDFOjR4DHhRfqgNqWCE4eljOm442hXztEta5Y7+AnTDNtK0SxKmMxKcSPEBaVRgMhM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774483037; c=relaxed/simple; bh=b3rC6hR82s7Sj9fmU9Bmvjfv+VSj3BR0pCSd0SQMDTg=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=KlIZKNiAo9L5RzLAd5aUHnrI8TKH/+g6FQvRCz8c3lcRZk5DTwubPT5CnSV8TqdN89zE3oFYJtVBns9S45dAdG9QcuSx2YAP9kvNFHN1K1s0/uQJ9ZflFDPGzvCsGMHfeQndyNLiVsFCiTxU5cH3CH5WZ7+OP1Zpb3QJNF+F74w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=J7dVm3oH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="J7dVm3oH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 85DB0C4CEF7; Wed, 25 Mar 2026 23:57:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1774483037; bh=b3rC6hR82s7Sj9fmU9Bmvjfv+VSj3BR0pCSd0SQMDTg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=J7dVm3oHxaqbESIAhtHy/bRJtU3jMAYnjBfyqsVKCpUV/oYma6wQBIy43T1apTF5d +oYJcB1kApd10QnaJnvJ70khNnecrLLls2qcuD1K85jNf6ub9QlRv6dxjx4crlmv5V w0oyR8ZjbbnX9dQ/51UFQKfcqL8FQHZEYc3h6LHM= Date: Wed, 25 Mar 2026 16:57:16 -0700 From: Andrew Morton To: Qi Zheng Cc: hannes@cmpxchg.org, hughd@google.com, mhocko@suse.com, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, david@kernel.org, ljs@kernel.org, ziy@nvidia.com, harry.yoo@oracle.com, yosry.ahmed@linux.dev, imran.f.khan@oracle.com, kamalesh.babulal@oracle.com, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, chenridong@huaweicloud.com, mkoutny@suse.com, hamzamahfooz@linux.microsoft.com, apais@linux.microsoft.com, lance.yang@linux.dev, bhe@redhat.com, usamaarif642@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Qi Zheng Subject: Re: [PATCH v2 0/4] fix unexpected type conversions and potential overflows Message-Id: <20260325165716.5d63522ba825f25a63e74e3e@linux-foundation.org> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 25 Mar 2026 22:13:21 +0800 Qi Zheng wrote: > As Harry Yoo pointed out [1], in scenarios where massive state updates occur > (e.g., during the reparenting of LRU folios), the values passed to memcg stat > update functions can accumulate and exceed the upper limit of a 32-bit integer. > > If the parameter types are not large enough (like 'int') or are handled > incorrectly, it can lead to severe truncation, potential overflow issues, > and unexpected type conversion bugs. > > This series aims to address these issues by correcting the parameter types > in the relevant functions, and fixing an implicit conversion bug in > memcg_state_val_in_pages(). Thanks. I'll add this to mm.git's mm-new branch. AI review (https://sashiko.dev/#/patchset/cover.1774447069.git.zhengqi.arch%40bytedance.com) still points at the problem in [2/4], now describing it as a bisection hole. In https://lkml.kernel.org/r/5fed0611-434c-4fd4-956c-39f23e0459a1@linux.dev you said you were going to address this by using abs(), and I see that being done in [4/4] so yup, runtime bisection hole. I'm inclined to mark this "don't care". But if we decide to backport [2/4] ("to prevent potential overflow issues") then we might have a problem. Also, if some downstream person decides to backport [2/4] into their kernel without [4/4] then they'll have a bad day. So perhaps this issue should be addressed within [2/4]?