Re: [PATCH v2 1/4] mm: memcontrol: correct the type of stats_updates to unsigned long

[Qi Zheng]

On 3/26/26 4:05 PM, Lorenzo Stoakes (Oracle) wrote:
> On Thu, Mar 26, 2026 at 10:32:43AM +0800, Qi Zheng wrote:
> > On 3/25/26 11:28 PM, Lorenzo Stoakes (Oracle) wrote:
> > > On Wed, Mar 25, 2026 at 10:13:22PM +0800, Qi Zheng wrote:
> > > > From: Qi Zheng <zhengqi.arch@xxxxxxxxxxxxx>
> > > >
> > > > The memcg_rstat_updated() tracks updates for vmstats_percpu->state
> > > > and lruvec_stats_percpu->state. Since these state values are of type long,
> > > > change the val parameter passed to memcg_rstat_updated() to long as well.
> > > >
> > > > Correspondingly, change the type of stats_updates in struct
> > > > memcg_vmstats_percpu and struct memcg_vmstats from unsigned int and
> > > > atomic_t to unsigned long and atomic_long_t respectively to prevent
> > > > potential overflow when handling large state updates during the
> > > > reparenting of LRU folios.
> > >
> > > Do we need a Fixes, possibly cc: stable for that? Apologies if already
> > > asked + answered.
> >
> > Before LRU folio reparenting was introduced, we wouldn’t pass in such a
> > large value, so this wasn’t a problem. Since LRU folio reparenting is
> > still in mm-unstable, so I didn't add a Fixes tag in [4/4].
>
> Ah, well these patches should be _before_ the LRU folio reparenting then?
>
> Andrew - can we ensure correct ordering here?

There are some dependencies for this.

To be precise, it should be applied after:

[PATCH v6 29/33] mm: memcontrol: refactor mod_memcg_state() and 
mod_memcg_lruvec_state()

and before:

[PATCH v6 32/33] mm: memcontrol: eliminate the problem of dying memory 
cgroup for LRU folios

and there might be conflicts.

Would it be okay to merge them together into v7.1-rcX? Otherwise,
perhaps updating to v7 would be more convenient for Andrew.

Hi Andrew, what do you think?

Thanks,
Qi

> > > > Signed-off-by: Qi Zheng <zhengqi.arch@xxxxxxxxxxxxx>
> > >
> > > Anyway logic seems fine to me, so:
> > >
> > > Reviewed-by: Lorenzo Stoakes (Oracle) <ljs@xxxxxxxxxx>
> >
> > Thanks!
>
> Thanks, Lorenzo