From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-186.mta0.migadu.com (out-186.mta0.migadu.com [91.218.175.186]) (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 1870C391509 for ; Thu, 26 Mar 2026 02:30:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.186 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774492255; cv=none; b=hcd5i+tKVJeYex5cFhFEhdU7N0h5vDCzktDXpPG0JQOZMZyStEJiBTUY/PgbsgYh6F/Cp9fXH8gJRBddMGKHc8Oo3bHDTN9NDqkNVzC1aVrhU24MTrfAhdfdh5f/Z7mZFOCM+pgLvF3GU5+XG8GeXh3ZpIPjfQP5vYM8K66pLgc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774492255; c=relaxed/simple; bh=LLMHPLrTKl33P/3Aa+MJtGXxhnArJAD9MKpcdAv1y0A=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=s2fxnIAz3ZPltunyuxGvCjMJzC7XjJVbyNq7NqUh5kC+ZiVoOR1NFzcdhoK+QqLqWHcpSx47YJjF+4eTQXGlPJTCL+zJ6uM2mhjszz5baw8+VTjwMoQzbzFucuJSi4+b4PPBmzxIgJ+Vfv404Bbfa2lyLrOBE+LpWAPCki4EjXE= 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=PojcR6lX; arc=none smtp.client-ip=91.218.175.186 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="PojcR6lX" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1774492249; 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=9sZcKKartCLEcGbdRuk8RU9rrHH+1C3boMhyXvYq+RU=; b=PojcR6lX910Q62jsSKfarzUo+MopTCDJjRkHWIFggMJ6nHYM7fKsOt6mdJXMi0msGNb5h2 w5GvUF2aXHLDoX+SyTl+jMG7vZ3XjYp4hcWzQt/Z89RmVxHlnGmuLREi0RHO+8/SUcWOo8 q5DtLI74uMtl7SgbHpf1hLk2dyGAUdg= Date: Thu, 26 Mar 2026 10:30:29 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v2 0/4] fix unexpected type conversions and potential overflows To: Andrew Morton 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 References: <20260325165716.5d63522ba825f25a63e74e3e@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: <20260325165716.5d63522ba825f25a63e74e3e@linux-foundation.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 3/26/26 7:57 AM, Andrew Morton wrote: > 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. Right. > > 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. As Harry Yoo pointed out: ``` Let's look at an example (assuming unit is 1). val = val * unit = -16384 (-16 KiB) val * unit / PAGE_SIZE = 0xFFFFFFFFFFFFC000 / PAGE_SIZE = 0x3FFFFFFFFFFFFF max(0x3FFFFFFFFFFFFF, 1UL) = 0x3FFFFFFFFFF Yeah, that's a massive positive number. Hmm but how did it work when it was int? val = val * unit = -16384 (-16KiB) val * unit / PAGE_SIZE = 0xFFFFFFFFFFFFC000 / PAGE_SIZE = 0x3FFFFFFFFFFFFF max(val * unit / PAGE_SIZE, 1UL) = 0x3FFFFFFFFFFFFF (int)0x3FFFFFFFFFFFFF = 0xFFFFFFFF = (-1) That's incorrect. It should have been -4? ``` this can already be an issue even without [2/4], and [2/4] just amplify it. Before LRU folio reparenting was introduced, we wouldn’t pass in such a large value, so this wasn’t a problem. Since LRU folio reparenting is still in mm-unstable, so I didn't add a Fixes tag in [4/4]. > > So perhaps this issue should be addressed within [2/4]? Because they fix different existing problems, I previously split them into two patches. However, since the issues are all quite minor, I feel that combining them into a single patch is fine. >> Actually I can trivially do this locally if you like - just turn [4/4] i>> nto a -fix patch against [2/4], squash them together later on. >> >> Please lmk if you'd like me to do that. That's fine, thank you!