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

Qi Zheng
2026-03-27T02:43:11Z

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.
>