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

[Qi Zheng]

On 3/27/26 8:06 AM, Andrew Morton wrote:
> On Thu, 26 Mar 2026 09:38:02 +0000 "Lorenzo Stoakes (Oracle)" <ljs@xxxxxxxxxx> 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@xxxxxxxxxxxxx/
> >
> > 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.