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

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

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@bytedance.com>
>>>>
>>>> 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@bytedance.com>
>>>
>>> Anyway logic seems fine to me, so:
>>>
>>> Reviewed-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
>>
>> Thanks!
>>
>>
> 
> Thanks, Lorenzo