Re: [PATCH v2 4/4] mm: memcontrol: fix unexpected massive positive number in memcg_state_val_in_pages()

[Qi Zheng <qi.zheng@linux.dev>]

On 3/27/26 8:06 AM, Andrew Morton wrote:
> On Thu, 26 Mar 2026 09:38:02 +0000 "Lorenzo Stoakes (Oracle)" <ljs@kernel.org> wrote:
> 
>>>
>>> If Andrew needs me to merge this patchset into "[PATCH v6 00/33] Eliminate
>>> Dying Memory Cgroup" [1], then I will develop and send v7.
>>>
>>> [1].
>>> https://lore.kernel.org/all/cover.1772711148.git.zhengqi.arch@bytedance.com/
>>
>> Oh that's your series too :)
>>
>> That would be ideal unless that's already in mm-stable, as the series ordering
>> will give us strict ordering on patches.
>>
>> Anyway let's wait for Andrew on that!
> 
> <trying to catch up here>
> 
> Gee, I'd rather not churn that 33 patch series.  Could of course do so

Agree.

> in the normal fashion, if that's considered particularly desirable.
> 
> As I understand it, Qi will be preparing a v3 and I should stage that
> ahead of "Eliminate ..." to avoid a bisection hole?
> 
> If so, that works.
> 
> <checks>
> 
> Well dang, this series ("fix unexpected type conversions and potential
> overflows") is at least textually dependent on "Eliminate ...".
> 
> Options:
> 
> a) Redo this "fix unexpected ..." series on top of "Eliminate ..."
>     and tolerate the bisection hole (easiest).

 From my personal perspective, I prefer this approach. The issues fixed
by this patchset aren't too critical; it's just that the counter might
overflow (and only with CONFIG_MEMCG_V1). If it can be included in
v7.1-rcX along with "Eliminate ...", I think it's acceptable.

Thanks,
Qi

> 
>     Am I correct in believing that the concern here is a runtime
>     bisection hole?  And that the bug is pretty unlikely to hit even if
>     our unlucky bisector happens to hit that hole?  If so, we can live
>     with that, surely.  Every darn hotfix we do creates a runtime
>     bisecton hole!
> 
> b) Redo this series on top of mm-stable or mainline or whatever then
>     I stage this series ahead of "Eliminate ..." and fix up the merge
>     issues (probably OK)
> 
> c) Qi redoes everything as a single series.  That's OK.
> 
> If we choose c) then please lmk and I'll drop both series to give Qi a
> clean run at mm-unstable.
>