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

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

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

   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.