Re: [PATCH v2 0/4] fix unexpected type conversions and potential overflows

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 25 Mar 2026 22:13:21 +0800 Qi Zheng <qi.zheng@linux.dev> 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]?