[PATCH v2 0/4] fix unexpected type conversions and potential overflows

[PATCH v2 0/4] fix unexpected type conversions and potential overflows

[Qi Zheng]

From: Qi Zheng <zhengqi.arch@bytedance.com>

Hi all,

As Harry Yoo pointed out [1], in scenarios where massive state updates occur
(e.g., during the reparenting of LRU folios), the values passed to memcg stat
update functions can accumulate and exceed the upper limit of a 32-bit integer.

If the parameter types are not large enough (like 'int') or are handled
incorrectly, it can lead to severe truncation, potential overflow issues,
and unexpected type conversion bugs.

This series aims to address these issues by correcting the parameter types
in the relevant functions, and fixing an implicit conversion bug in
memcg_state_val_in_pages().

This series is based on the next-20260323.

Comments and suggestions are welcome!

Thanks,
Qi

[1]. https://lore.kernel.org/all/acDxaEgnqPI-Z4be@hyeyoo/

Qi Zheng (4):
  mm: memcontrol: correct the type of stats_updates to unsigned long
  mm: memcontrol: change val type to long in
    __mod_memcg_{lruvec_}state()
  mm: memcontrol: correct the nr_pages parameter type of
    mem_cgroup_update_lru_size()
  mm: memcontrol: fix unexpected massive positive number in
    memcg_state_val_in_pages()

 include/linux/memcontrol.h   |  2 +-
 include/trace/events/memcg.h | 10 +++++-----
 mm/memcontrol.c              | 37 +++++++++++++++++++-----------------
 3 files changed, 26 insertions(+), 23 deletions(-)

-- 
2.20.1

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

[Qi Zheng]

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.

Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
---
 mm/memcontrol.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index a47fb68dd65f1..7fb9cbc10dfbb 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -608,7 +608,7 @@ static inline int memcg_events_index(enum vm_event_item idx)
 
 struct memcg_vmstats_percpu {
 	/* Stats updates since the last flush */
-	unsigned int			stats_updates;
+	unsigned long			stats_updates;
 
 	/* Cached pointers for fast iteration in memcg_rstat_updated() */
 	struct memcg_vmstats_percpu __percpu	*parent_pcpu;
@@ -639,7 +639,7 @@ struct memcg_vmstats {
 	unsigned long		events_pending[NR_MEMCG_EVENTS];
 
 	/* Stats updates since the last flush */
-	atomic_t		stats_updates;
+	atomic_long_t		stats_updates;
 };
 
 /*
@@ -665,16 +665,16 @@ static u64 flush_last_time;
 
 static bool memcg_vmstats_needs_flush(struct memcg_vmstats *vmstats)
 {
-	return atomic_read(&vmstats->stats_updates) >
+	return atomic_long_read(&vmstats->stats_updates) >
 		MEMCG_CHARGE_BATCH * num_online_cpus();
 }
 
-static inline void memcg_rstat_updated(struct mem_cgroup *memcg, int val,
+static inline void memcg_rstat_updated(struct mem_cgroup *memcg, long val,
 				       int cpu)
 {
 	struct memcg_vmstats_percpu __percpu *statc_pcpu;
 	struct memcg_vmstats_percpu *statc;
-	unsigned int stats_updates;
+	unsigned long stats_updates;
 
 	if (!val)
 		return;
@@ -697,7 +697,7 @@ static inline void memcg_rstat_updated(struct mem_cgroup *memcg, int val,
 			continue;
 
 		stats_updates = this_cpu_xchg(statc_pcpu->stats_updates, 0);
-		atomic_add(stats_updates, &statc->vmstats->stats_updates);
+		atomic_long_add(stats_updates, &statc->vmstats->stats_updates);
 	}
 }
 
@@ -705,7 +705,7 @@ static void __mem_cgroup_flush_stats(struct mem_cgroup *memcg, bool force)
 {
 	bool needs_flush = memcg_vmstats_needs_flush(memcg->vmstats);
 
-	trace_memcg_flush_stats(memcg, atomic_read(&memcg->vmstats->stats_updates),
+	trace_memcg_flush_stats(memcg, atomic_long_read(&memcg->vmstats->stats_updates),
 		force, needs_flush);
 
 	if (!force && !needs_flush)
@@ -4406,8 +4406,8 @@ static void mem_cgroup_css_rstat_flush(struct cgroup_subsys_state *css, int cpu)
 	}
 	WRITE_ONCE(statc->stats_updates, 0);
 	/* We are in a per-cpu loop here, only do the atomic write once */
-	if (atomic_read(&memcg->vmstats->stats_updates))
-		atomic_set(&memcg->vmstats->stats_updates, 0);
+	if (atomic_long_read(&memcg->vmstats->stats_updates))
+		atomic_long_set(&memcg->vmstats->stats_updates, 0);
 }
 
 static void mem_cgroup_fork(struct task_struct *task)
-- 
2.20.1

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

[Lorenzo Stoakes (Oracle)]

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.

>
> Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>

Anyway logic seems fine to me, so:

Reviewed-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>

> ---
>  mm/memcontrol.c | 18 +++++++++---------
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index a47fb68dd65f1..7fb9cbc10dfbb 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -608,7 +608,7 @@ static inline int memcg_events_index(enum vm_event_item idx)
>
>  struct memcg_vmstats_percpu {
>  	/* Stats updates since the last flush */
> -	unsigned int			stats_updates;
> +	unsigned long			stats_updates;
>
>  	/* Cached pointers for fast iteration in memcg_rstat_updated() */
>  	struct memcg_vmstats_percpu __percpu	*parent_pcpu;
> @@ -639,7 +639,7 @@ struct memcg_vmstats {
>  	unsigned long		events_pending[NR_MEMCG_EVENTS];
>
>  	/* Stats updates since the last flush */
> -	atomic_t		stats_updates;
> +	atomic_long_t		stats_updates;
>  };
>
>  /*
> @@ -665,16 +665,16 @@ static u64 flush_last_time;
>
>  static bool memcg_vmstats_needs_flush(struct memcg_vmstats *vmstats)
>  {
> -	return atomic_read(&vmstats->stats_updates) >
> +	return atomic_long_read(&vmstats->stats_updates) >
>  		MEMCG_CHARGE_BATCH * num_online_cpus();
>  }
>
> -static inline void memcg_rstat_updated(struct mem_cgroup *memcg, int val,
> +static inline void memcg_rstat_updated(struct mem_cgroup *memcg, long val,
>  				       int cpu)
>  {
>  	struct memcg_vmstats_percpu __percpu *statc_pcpu;
>  	struct memcg_vmstats_percpu *statc;
> -	unsigned int stats_updates;
> +	unsigned long stats_updates;
>
>  	if (!val)
>  		return;
> @@ -697,7 +697,7 @@ static inline void memcg_rstat_updated(struct mem_cgroup *memcg, int val,
>  			continue;
>
>  		stats_updates = this_cpu_xchg(statc_pcpu->stats_updates, 0);
> -		atomic_add(stats_updates, &statc->vmstats->stats_updates);
> +		atomic_long_add(stats_updates, &statc->vmstats->stats_updates);
>  	}
>  }
>
> @@ -705,7 +705,7 @@ static void __mem_cgroup_flush_stats(struct mem_cgroup *memcg, bool force)
>  {
>  	bool needs_flush = memcg_vmstats_needs_flush(memcg->vmstats);
>
> -	trace_memcg_flush_stats(memcg, atomic_read(&memcg->vmstats->stats_updates),
> +	trace_memcg_flush_stats(memcg, atomic_long_read(&memcg->vmstats->stats_updates),
>  		force, needs_flush);
>
>  	if (!force && !needs_flush)
> @@ -4406,8 +4406,8 @@ static void mem_cgroup_css_rstat_flush(struct cgroup_subsys_state *css, int cpu)
>  	}
>  	WRITE_ONCE(statc->stats_updates, 0);
>  	/* We are in a per-cpu loop here, only do the atomic write once */
> -	if (atomic_read(&memcg->vmstats->stats_updates))
> -		atomic_set(&memcg->vmstats->stats_updates, 0);
> +	if (atomic_long_read(&memcg->vmstats->stats_updates))
> +		atomic_long_set(&memcg->vmstats->stats_updates, 0);
>  }
>
>  static void mem_cgroup_fork(struct task_struct *task)
> --
> 2.20.1
>

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

[Qi Zheng]

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

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

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

[Lorenzo Stoakes (Oracle)]

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?

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

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

[Harry Yoo (Oracle)]

On Thu, Mar 26, 2026 at 08:05:57AM +0000, 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?

Yes. I think that'll be the best option.

If that's too much of a headache at this point (I'm not sure),
it should be at least part of 7.1-rcX, given that it's quite unlikely
that people will notice it during bisection anyway...

-- 
Cheers,
Harry / Hyeonggon

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

[PATCH v2 2/4] mm: memcontrol: change val type to long in __mod_memcg_{lruvec_}state()

[Qi Zheng]

From: Qi Zheng <zhengqi.arch@bytedance.com>

The __mod_memcg_state() and __mod_memcg_lruvec_state() functions are also
used to reparent non-hierarchical stats. In this scenario, the values
passed to them are accumulated statistics that might be extremely large
and exceed the upper limit of a 32-bit integer.

Change the val parameter type from int to long in these functions and
their corresponding tracepoints (memcg_rstat_stats) to prevent potential
overflow issues.

Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
---
 include/trace/events/memcg.h | 10 +++++-----
 mm/memcontrol.c              |  8 ++++----
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/include/trace/events/memcg.h b/include/trace/events/memcg.h
index dfe2f51019b4c..51b62c5931fc2 100644
--- a/include/trace/events/memcg.h
+++ b/include/trace/events/memcg.h
@@ -11,14 +11,14 @@
 
 DECLARE_EVENT_CLASS(memcg_rstat_stats,
 
-	TP_PROTO(struct mem_cgroup *memcg, int item, int val),
+	TP_PROTO(struct mem_cgroup *memcg, int item, long val),
 
 	TP_ARGS(memcg, item, val),
 
 	TP_STRUCT__entry(
 		__field(u64, id)
 		__field(int, item)
-		__field(int, val)
+		__field(long, val)
 	),
 
 	TP_fast_assign(
@@ -27,20 +27,20 @@ DECLARE_EVENT_CLASS(memcg_rstat_stats,
 		__entry->val = val;
 	),
 
-	TP_printk("memcg_id=%llu item=%d val=%d",
+	TP_printk("memcg_id=%llu item=%d val=%ld",
 		  __entry->id, __entry->item, __entry->val)
 );
 
 DEFINE_EVENT(memcg_rstat_stats, mod_memcg_state,
 
-	TP_PROTO(struct mem_cgroup *memcg, int item, int val),
+	TP_PROTO(struct mem_cgroup *memcg, int item, long val),
 
 	TP_ARGS(memcg, item, val)
 );
 
 DEFINE_EVENT(memcg_rstat_stats, mod_memcg_lruvec_state,
 
-	TP_PROTO(struct mem_cgroup *memcg, int item, int val),
+	TP_PROTO(struct mem_cgroup *memcg, int item, long val),
 
 	TP_ARGS(memcg, item, val)
 );
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 7fb9cbc10dfbb..4a78550f6174e 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -527,7 +527,7 @@ unsigned long lruvec_page_state_local(struct lruvec *lruvec,
 
 #ifdef CONFIG_MEMCG_V1
 static void __mod_memcg_lruvec_state(struct mem_cgroup_per_node *pn,
-				     enum node_stat_item idx, int val);
+				     enum node_stat_item idx, long val);
 
 void reparent_memcg_lruvec_state_local(struct mem_cgroup *memcg,
 				       struct mem_cgroup *parent, int idx)
@@ -784,7 +784,7 @@ static int memcg_page_state_unit(int item);
  * Normalize the value passed into memcg_rstat_updated() to be in pages. Round
  * up non-zero sub-page updates to 1 page as zero page updates are ignored.
  */
-static int memcg_state_val_in_pages(int idx, int val)
+static long memcg_state_val_in_pages(int idx, long val)
 {
 	int unit = memcg_page_state_unit(idx);
 
@@ -831,7 +831,7 @@ static inline void get_non_dying_memcg_end(void)
 #endif
 
 static void __mod_memcg_state(struct mem_cgroup *memcg,
-			      enum memcg_stat_item idx, int val)
+			      enum memcg_stat_item idx, long val)
 {
 	int i = memcg_stats_index(idx);
 	int cpu;
@@ -896,7 +896,7 @@ void reparent_memcg_state_local(struct mem_cgroup *memcg,
 #endif
 
 static void __mod_memcg_lruvec_state(struct mem_cgroup_per_node *pn,
-				     enum node_stat_item idx, int val)
+				     enum node_stat_item idx, long val)
 {
 	struct mem_cgroup *memcg = pn->memcg;
 	int i = memcg_stats_index(idx);
-- 
2.20.1

Re: [PATCH v2 2/4] mm: memcontrol: change val type to long in __mod_memcg_{lruvec_}state()

[Lorenzo Stoakes (Oracle)]

On Wed, Mar 25, 2026 at 10:13:23PM +0800, Qi Zheng wrote:
> From: Qi Zheng <zhengqi.arch@bytedance.com>
>
> The __mod_memcg_state() and __mod_memcg_lruvec_state() functions are also
> used to reparent non-hierarchical stats. In this scenario, the values
> passed to them are accumulated statistics that might be extremely large
> and exceed the upper limit of a 32-bit integer.
>
> Change the val parameter type from int to long in these functions and
> their corresponding tracepoints (memcg_rstat_stats) to prevent potential
> overflow issues.
>
> Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>

LGTM, so:

Reviewed-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>

> ---
>  include/trace/events/memcg.h | 10 +++++-----
>  mm/memcontrol.c              |  8 ++++----
>  2 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/include/trace/events/memcg.h b/include/trace/events/memcg.h
> index dfe2f51019b4c..51b62c5931fc2 100644
> --- a/include/trace/events/memcg.h
> +++ b/include/trace/events/memcg.h
> @@ -11,14 +11,14 @@
>
>  DECLARE_EVENT_CLASS(memcg_rstat_stats,
>
> -	TP_PROTO(struct mem_cgroup *memcg, int item, int val),
> +	TP_PROTO(struct mem_cgroup *memcg, int item, long val),
>
>  	TP_ARGS(memcg, item, val),
>
>  	TP_STRUCT__entry(
>  		__field(u64, id)
>  		__field(int, item)
> -		__field(int, val)
> +		__field(long, val)
>  	),
>
>  	TP_fast_assign(
> @@ -27,20 +27,20 @@ DECLARE_EVENT_CLASS(memcg_rstat_stats,
>  		__entry->val = val;
>  	),
>
> -	TP_printk("memcg_id=%llu item=%d val=%d",
> +	TP_printk("memcg_id=%llu item=%d val=%ld",
>  		  __entry->id, __entry->item, __entry->val)
>  );
>
>  DEFINE_EVENT(memcg_rstat_stats, mod_memcg_state,
>
> -	TP_PROTO(struct mem_cgroup *memcg, int item, int val),
> +	TP_PROTO(struct mem_cgroup *memcg, int item, long val),
>
>  	TP_ARGS(memcg, item, val)
>  );
>
>  DEFINE_EVENT(memcg_rstat_stats, mod_memcg_lruvec_state,
>
> -	TP_PROTO(struct mem_cgroup *memcg, int item, int val),
> +	TP_PROTO(struct mem_cgroup *memcg, int item, long val),
>
>  	TP_ARGS(memcg, item, val)
>  );
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 7fb9cbc10dfbb..4a78550f6174e 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -527,7 +527,7 @@ unsigned long lruvec_page_state_local(struct lruvec *lruvec,
>
>  #ifdef CONFIG_MEMCG_V1
>  static void __mod_memcg_lruvec_state(struct mem_cgroup_per_node *pn,
> -				     enum node_stat_item idx, int val);
> +				     enum node_stat_item idx, long val);
>
>  void reparent_memcg_lruvec_state_local(struct mem_cgroup *memcg,
>  				       struct mem_cgroup *parent, int idx)
> @@ -784,7 +784,7 @@ static int memcg_page_state_unit(int item);
>   * Normalize the value passed into memcg_rstat_updated() to be in pages. Round
>   * up non-zero sub-page updates to 1 page as zero page updates are ignored.
>   */
> -static int memcg_state_val_in_pages(int idx, int val)
> +static long memcg_state_val_in_pages(int idx, long val)
>  {
>  	int unit = memcg_page_state_unit(idx);
>
> @@ -831,7 +831,7 @@ static inline void get_non_dying_memcg_end(void)
>  #endif
>
>  static void __mod_memcg_state(struct mem_cgroup *memcg,
> -			      enum memcg_stat_item idx, int val)
> +			      enum memcg_stat_item idx, long val)
>  {
>  	int i = memcg_stats_index(idx);
>  	int cpu;
> @@ -896,7 +896,7 @@ void reparent_memcg_state_local(struct mem_cgroup *memcg,
>  #endif
>
>  static void __mod_memcg_lruvec_state(struct mem_cgroup_per_node *pn,
> -				     enum node_stat_item idx, int val)
> +				     enum node_stat_item idx, long val)
>  {
>  	struct mem_cgroup *memcg = pn->memcg;
>  	int i = memcg_stats_index(idx);
> --
> 2.20.1
>

Re: [PATCH v2 2/4] mm: memcontrol: change val type to long in __mod_memcg_{lruvec_}state()

[David Laight]

On Thu, 26 Mar 2026 09:19:29 +0000
"Lorenzo Stoakes (Oracle)" <ljs@kernel.org> wrote:

> On Wed, Mar 25, 2026 at 10:13:23PM +0800, Qi Zheng wrote:
> > From: Qi Zheng <zhengqi.arch@bytedance.com>
> >
> > The __mod_memcg_state() and __mod_memcg_lruvec_state() functions are also
> > used to reparent non-hierarchical stats. In this scenario, the values
> > passed to them are accumulated statistics that might be extremely large
> > and exceed the upper limit of a 32-bit integer.
> >
> > Change the val parameter type from int to long in these functions and
> > their corresponding tracepoints (memcg_rstat_stats) to prevent potential
> > overflow issues.

Won't that are be true on 32bit systems?
Which means the underlying values need to be u64 not long.

	David

> >
> > Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>  
> 
> LGTM, so:
> 
> Reviewed-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
> 
> > ---
> >  include/trace/events/memcg.h | 10 +++++-----
> >  mm/memcontrol.c              |  8 ++++----
> >  2 files changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/include/trace/events/memcg.h b/include/trace/events/memcg.h
> > index dfe2f51019b4c..51b62c5931fc2 100644
> > --- a/include/trace/events/memcg.h
> > +++ b/include/trace/events/memcg.h
> > @@ -11,14 +11,14 @@
> >
> >  DECLARE_EVENT_CLASS(memcg_rstat_stats,
> >
> > -	TP_PROTO(struct mem_cgroup *memcg, int item, int val),
> > +	TP_PROTO(struct mem_cgroup *memcg, int item, long val),
> >
> >  	TP_ARGS(memcg, item, val),
> >
> >  	TP_STRUCT__entry(
> >  		__field(u64, id)
> >  		__field(int, item)
> > -		__field(int, val)
> > +		__field(long, val)
> >  	),
> >
> >  	TP_fast_assign(
> > @@ -27,20 +27,20 @@ DECLARE_EVENT_CLASS(memcg_rstat_stats,
> >  		__entry->val = val;
> >  	),
> >
> > -	TP_printk("memcg_id=%llu item=%d val=%d",
> > +	TP_printk("memcg_id=%llu item=%d val=%ld",
> >  		  __entry->id, __entry->item, __entry->val)
> >  );
> >
> >  DEFINE_EVENT(memcg_rstat_stats, mod_memcg_state,
> >
> > -	TP_PROTO(struct mem_cgroup *memcg, int item, int val),
> > +	TP_PROTO(struct mem_cgroup *memcg, int item, long val),
> >
> >  	TP_ARGS(memcg, item, val)
> >  );
> >
> >  DEFINE_EVENT(memcg_rstat_stats, mod_memcg_lruvec_state,
> >
> > -	TP_PROTO(struct mem_cgroup *memcg, int item, int val),
> > +	TP_PROTO(struct mem_cgroup *memcg, int item, long val),
> >
> >  	TP_ARGS(memcg, item, val)
> >  );
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index 7fb9cbc10dfbb..4a78550f6174e 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -527,7 +527,7 @@ unsigned long lruvec_page_state_local(struct lruvec *lruvec,
> >
> >  #ifdef CONFIG_MEMCG_V1
> >  static void __mod_memcg_lruvec_state(struct mem_cgroup_per_node *pn,
> > -				     enum node_stat_item idx, int val);
> > +				     enum node_stat_item idx, long val);
> >
> >  void reparent_memcg_lruvec_state_local(struct mem_cgroup *memcg,
> >  				       struct mem_cgroup *parent, int idx)
> > @@ -784,7 +784,7 @@ static int memcg_page_state_unit(int item);
> >   * Normalize the value passed into memcg_rstat_updated() to be in pages. Round
> >   * up non-zero sub-page updates to 1 page as zero page updates are ignored.
> >   */
> > -static int memcg_state_val_in_pages(int idx, int val)
> > +static long memcg_state_val_in_pages(int idx, long val)
> >  {
> >  	int unit = memcg_page_state_unit(idx);
> >
> > @@ -831,7 +831,7 @@ static inline void get_non_dying_memcg_end(void)
> >  #endif
> >
> >  static void __mod_memcg_state(struct mem_cgroup *memcg,
> > -			      enum memcg_stat_item idx, int val)
> > +			      enum memcg_stat_item idx, long val)
> >  {
> >  	int i = memcg_stats_index(idx);
> >  	int cpu;
> > @@ -896,7 +896,7 @@ void reparent_memcg_state_local(struct mem_cgroup *memcg,
> >  #endif
> >
> >  static void __mod_memcg_lruvec_state(struct mem_cgroup_per_node *pn,
> > -				     enum node_stat_item idx, int val)
> > +				     enum node_stat_item idx, long val)
> >  {
> >  	struct mem_cgroup *memcg = pn->memcg;
> >  	int i = memcg_stats_index(idx);
> > --
> > 2.20.1
> >  
> 

[PATCH v2 3/4] mm: memcontrol: correct the nr_pages parameter type of mem_cgroup_update_lru_size()

[Qi Zheng]

From: Qi Zheng <zhengqi.arch@bytedance.com>

The nr_pages parameter of mem_cgroup_update_lru_size() represents a page
count. During the reparenting of LRU folios, the value passed to it can
potentially exceed the maximum value of a 32-bit integer. It should be
declared as long instead of int to match the types used in lruvec size
accounting and to prevent possible overflow.

Update the parameter type to long to ensure correctness.

Reviewed-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
---
 include/linux/memcontrol.h | 2 +-
 mm/memcontrol.c            | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 0861589695298..dc3fa687759b4 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -878,7 +878,7 @@ static inline bool mem_cgroup_online(struct mem_cgroup *memcg)
 }
 
 void mem_cgroup_update_lru_size(struct lruvec *lruvec, enum lru_list lru,
-		int zid, int nr_pages);
+		int zid, long nr_pages);
 
 static inline
 unsigned long mem_cgroup_get_zone_lru_size(struct lruvec *lruvec,
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 4a78550f6174e..04076a139dbe3 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1466,7 +1466,7 @@ struct lruvec *folio_lruvec_lock_irqsave(struct folio *folio,
  * to or just after a page is removed from an lru list.
  */
 void mem_cgroup_update_lru_size(struct lruvec *lruvec, enum lru_list lru,
-				int zid, int nr_pages)
+				int zid, long nr_pages)
 {
 	struct mem_cgroup_per_node *mz;
 	unsigned long *lru_size;
@@ -1483,7 +1483,7 @@ void mem_cgroup_update_lru_size(struct lruvec *lruvec, enum lru_list lru,
 
 	size = *lru_size;
 	if (WARN_ONCE(size < 0,
-		"%s(%p, %d, %d): lru_size %ld\n",
+		"%s(%p, %d, %ld): lru_size %ld\n",
 		__func__, lruvec, lru, nr_pages, size)) {
 		VM_BUG_ON(1);
 		*lru_size = 0;
-- 
2.20.1

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

[Qi Zheng]

From: Qi Zheng <zhengqi.arch@bytedance.com>

In memcg_state_val_in_pages(), if the passed val is negative, the
expression val * unit / PAGE_SIZE could be implicitly converted to a
massive positive number when compared with 1UL in the max() macro.
This leads to returning an incorrect massive positive value.

Fix this by using abs(val) to calculate the magnitude first, and then
restoring the sign of the value before returning the result. Additionally,
use mult_frac() to prevent potential overflow during the multiplication of
val and unit.

Reported-by: Harry Yoo (Oracle) <harry@kernel.org>
Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
---
 mm/memcontrol.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 04076a139dbe3..0c249255ebefb 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -787,11 +787,14 @@ static int memcg_page_state_unit(int item);
 static long memcg_state_val_in_pages(int idx, long val)
 {
 	int unit = memcg_page_state_unit(idx);
+	long res;
 
 	if (!val || unit == PAGE_SIZE)
 		return val;
-	else
-		return max(val * unit / PAGE_SIZE, 1UL);
+
+	res = max(mult_frac(abs(val), unit, PAGE_SIZE), 1UL);
+
+	return val < 0 ? -res : res;
 }
 
 #ifdef CONFIG_MEMCG_V1
-- 
2.20.1

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

[Lorenzo Stoakes (Oracle)]

On Wed, Mar 25, 2026 at 10:13:25PM +0800, Qi Zheng wrote:
> From: Qi Zheng <zhengqi.arch@bytedance.com>
>
> In memcg_state_val_in_pages(), if the passed val is negative, the
> expression val * unit / PAGE_SIZE could be implicitly converted to a
> massive positive number when compared with 1UL in the max() macro.
> This leads to returning an incorrect massive positive value.
>
> Fix this by using abs(val) to calculate the magnitude first, and then
> restoring the sign of the value before returning the result. Additionally,
> use mult_frac() to prevent potential overflow during the multiplication of
> val and unit.
>
> Reported-by: Harry Yoo (Oracle) <harry@kernel.org>
> Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>

The logic is correct, but I think this needs rework for better
understanding, and obviously this should be squashed into 2/4 as per
Andrew.

With the below change applied:

Reviewed-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>

> ---
>  mm/memcontrol.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 04076a139dbe3..0c249255ebefb 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -787,11 +787,14 @@ static int memcg_page_state_unit(int item);
>  static long memcg_state_val_in_pages(int idx, long val)
>  {
>  	int unit = memcg_page_state_unit(idx);
> +	long res;
>
>  	if (!val || unit == PAGE_SIZE)
>  		return val;
> -	else
> -		return max(val * unit / PAGE_SIZE, 1UL);

Hm this was already fairly horrid, because we're comparing an unsigned long
value of 1 vs. a ULONG_MAX - abs(val) so this was intended to make 0 -> 1UL
but not what you'd mathematically think this was which was to make negative
values (logically < 1) -> 1.

Of course before it was just broken and would promote (val * unit /
PAGE_SIZE) to unsigned long first (thus massive number) and return that :)

> +
> +	res = max(mult_frac(abs(val), unit, PAGE_SIZE), 1UL);

This is way too compressed into one line and retains the confusing
behaviour.

Could we split this out and explain what we're doing (sign-extension,
integer promotion and all of this stuff is confusing - so let's just accept
that and spell it out):

	/* Get the absolute value of (val * unit / PAGE_SIZE). */
	res = mult_frac(abs(val), unit, PAGE_SIZE);
	/* Round up zero values. */
	res = res ?: 1;
	/* Retain sign. */
	return val < 0 ? -res : res;

This is functionally identical, but a lot more readable, I think.

> +
> +	return val < 0 ? -res : res;
>  }
>
>  #ifdef CONFIG_MEMCG_V1
> --
> 2.20.1
>

Cheers, Lorenzo

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

[Lorenzo Stoakes (Oracle)]

On Thu, Mar 26, 2026 at 09:16:50AM +0000, Lorenzo Stoakes (Oracle) wrote:
> 	/* Get the absolute value of (val * unit / PAGE_SIZE). */
> 	res = mult_frac(abs(val), unit, PAGE_SIZE);
> 	/* Round up zero values. */
> 	res = res ?: 1;
> 	/* Retain sign. */
> 	return val < 0 ? -res : res;

(If you think the comments are too much, you can drop them, and the code
essentially spells it out anyway)

Cheers, Lorenzo

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

[Qi Zheng]

On 3/26/26 5:16 PM, Lorenzo Stoakes (Oracle) wrote:
> On Wed, Mar 25, 2026 at 10:13:25PM +0800, Qi Zheng wrote:
>> From: Qi Zheng <zhengqi.arch@bytedance.com>
>>
>> In memcg_state_val_in_pages(), if the passed val is negative, the
>> expression val * unit / PAGE_SIZE could be implicitly converted to a
>> massive positive number when compared with 1UL in the max() macro.
>> This leads to returning an incorrect massive positive value.
>>
>> Fix this by using abs(val) to calculate the magnitude first, and then
>> restoring the sign of the value before returning the result. Additionally,
>> use mult_frac() to prevent potential overflow during the multiplication of
>> val and unit.
>>
>> Reported-by: Harry Yoo (Oracle) <harry@kernel.org>
>> Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
> 
> The logic is correct, but I think this needs rework for better
> understanding, and obviously this should be squashed into 2/4 as per
> Andrew.
> 
> With the below change applied:
> 
> Reviewed-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
> 
>> ---
>>   mm/memcontrol.c | 7 +++++--
>>   1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> index 04076a139dbe3..0c249255ebefb 100644
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
>> @@ -787,11 +787,14 @@ static int memcg_page_state_unit(int item);
>>   static long memcg_state_val_in_pages(int idx, long val)
>>   {
>>   	int unit = memcg_page_state_unit(idx);
>> +	long res;
>>
>>   	if (!val || unit == PAGE_SIZE)
>>   		return val;
>> -	else
>> -		return max(val * unit / PAGE_SIZE, 1UL);
> 
> Hm this was already fairly horrid, because we're comparing an unsigned long
> value of 1 vs. a ULONG_MAX - abs(val) so this was intended to make 0 -> 1UL
> but not what you'd mathematically think this was which was to make negative
> values (logically < 1) -> 1.
> 
> Of course before it was just broken and would promote (val * unit /
> PAGE_SIZE) to unsigned long first (thus massive number) and return that :)
> 
>> +
>> +	res = max(mult_frac(abs(val), unit, PAGE_SIZE), 1UL);
> 
> This is way too compressed into one line and retains the confusing
> behaviour.
> 
> Could we split this out and explain what we're doing (sign-extension,
> integer promotion and all of this stuff is confusing - so let's just accept
> that and spell it out):
> 
> 	/* Get the absolute value of (val * unit / PAGE_SIZE). */
> 	res = mult_frac(abs(val), unit, PAGE_SIZE);
> 	/* Round up zero values. */
> 	res = res ?: 1;
> 	/* Retain sign. */
> 	return val < 0 ? -res : res;
> 
> This is functionally identical, but a lot more readable, I think.

Make sense, I will update to v3.

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/

Thanks,
Qi

> 
>> +
>> +	return val < 0 ? -res : res;
>>   }
>>
>>   #ifdef CONFIG_MEMCG_V1
>> --
>> 2.20.1
>>
> 
> Cheers, Lorenzo

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

[Lorenzo Stoakes (Oracle)]

On Thu, Mar 26, 2026 at 05:32:05PM +0800, Qi Zheng wrote:
>
>
> On 3/26/26 5:16 PM, Lorenzo Stoakes (Oracle) wrote:
> > On Wed, Mar 25, 2026 at 10:13:25PM +0800, Qi Zheng wrote:
> > > ---
> > >   mm/memcontrol.c | 7 +++++--
> > >   1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > > index 04076a139dbe3..0c249255ebefb 100644
> > > --- a/mm/memcontrol.c
> > > +++ b/mm/memcontrol.c
> > > @@ -787,11 +787,14 @@ static int memcg_page_state_unit(int item);
> > >   static long memcg_state_val_in_pages(int idx, long val)
> > >   {
> > >   	int unit = memcg_page_state_unit(idx);
> > > +	long res;
> > >
> > >   	if (!val || unit == PAGE_SIZE)
> > >   		return val;
> > > -	else
> > > -		return max(val * unit / PAGE_SIZE, 1UL);
> >
> > Hm this was already fairly horrid, because we're comparing an unsigned long
> > value of 1 vs. a ULONG_MAX - abs(val) so this was intended to make 0 -> 1UL
> > but not what you'd mathematically think this was which was to make negative
> > values (logically < 1) -> 1.
> >
> > Of course before it was just broken and would promote (val * unit /
> > PAGE_SIZE) to unsigned long first (thus massive number) and return that :)
> >
> > > +
> > > +	res = max(mult_frac(abs(val), unit, PAGE_SIZE), 1UL);
> >
> > This is way too compressed into one line and retains the confusing
> > behaviour.
> >
> > Could we split this out and explain what we're doing (sign-extension,
> > integer promotion and all of this stuff is confusing - so let's just accept
> > that and spell it out):
> >
> > 	/* Get the absolute value of (val * unit / PAGE_SIZE). */
> > 	res = mult_frac(abs(val), unit, PAGE_SIZE);
> > 	/* Round up zero values. */
> > 	res = res ?: 1;
> > 	/* Retain sign. */
> > 	return val < 0 ? -res : res;
> >
> > This is functionally identical, but a lot more readable, I think.
>
> Make sense, I will update to v3.

Thanks!

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

Cheers, Lorenzo

Re: [PATCH v2 0/4] fix unexpected type conversions and potential overflows

[Qi Zheng]

Forgot to include the changelog:

Changes in v2:

  - modified all commit messages. (suggested-by Lorenzo Stoakes)
  - added a fix patch to resolve the unexpected massive positive number
    (pointed-by Harry Yoo and sashiko)
  - fix the print type mismatch in [PATCH 3/3]
  - collect Reviewed-by

On 3/25/26 10:13 PM, Qi Zheng wrote:
> From: Qi Zheng <zhengqi.arch@bytedance.com>
> 
> Hi all,
> 
> As Harry Yoo pointed out [1], in scenarios where massive state updates occur
> (e.g., during the reparenting of LRU folios), the values passed to memcg stat
> update functions can accumulate and exceed the upper limit of a 32-bit integer.
> 
> If the parameter types are not large enough (like 'int') or are handled
> incorrectly, it can lead to severe truncation, potential overflow issues,
> and unexpected type conversion bugs.
> 
> This series aims to address these issues by correcting the parameter types
> in the relevant functions, and fixing an implicit conversion bug in
> memcg_state_val_in_pages().
> 
> This series is based on the next-20260323.
> 
> Comments and suggestions are welcome!
> 
> Thanks,
> Qi
> 
> [1]. https://lore.kernel.org/all/acDxaEgnqPI-Z4be@hyeyoo/
> 
> Qi Zheng (4):
>    mm: memcontrol: correct the type of stats_updates to unsigned long
>    mm: memcontrol: change val type to long in
>      __mod_memcg_{lruvec_}state()
>    mm: memcontrol: correct the nr_pages parameter type of
>      mem_cgroup_update_lru_size()
>    mm: memcontrol: fix unexpected massive positive number in
>      memcg_state_val_in_pages()
> 
>   include/linux/memcontrol.h   |  2 +-
>   include/trace/events/memcg.h | 10 +++++-----
>   mm/memcontrol.c              | 37 +++++++++++++++++++-----------------
>   3 files changed, 26 insertions(+), 23 deletions(-)
> 

Re: [PATCH v2 0/4] fix unexpected type conversions and potential overflows

[Andrew Morton]

On Wed, 25 Mar 2026 22:13:21 +0800 Qi Zheng <qi.zheng@linux.dev> wrote:

> As Harry Yoo pointed out [1], in scenarios where massive state updates occur
> (e.g., during the reparenting of LRU folios), the values passed to memcg stat
> update functions can accumulate and exceed the upper limit of a 32-bit integer.
> 
> If the parameter types are not large enough (like 'int') or are handled
> incorrectly, it can lead to severe truncation, potential overflow issues,
> and unexpected type conversion bugs.
> 
> This series aims to address these issues by correcting the parameter types
> in the relevant functions, and fixing an implicit conversion bug in
> memcg_state_val_in_pages().

Thanks. I'll add this to mm.git's mm-new branch.

AI review
(https://sashiko.dev/#/patchset/cover.1774447069.git.zhengqi.arch%40bytedance.com)
still points at the problem in [2/4], now describing it as a bisection
hole.

In
https://lkml.kernel.org/r/5fed0611-434c-4fd4-956c-39f23e0459a1@linux.dev
you said you were going to address this by using abs(), and I see that
being done in [4/4] so yup, runtime bisection hole.

I'm inclined to mark this "don't care".  But if we decide to backport
[2/4] ("to prevent potential overflow issues") then we might have a
problem.

Also, if some downstream person decides to backport [2/4] into their
kernel without [4/4] then they'll have a bad day.

So perhaps this issue should be addressed within [2/4]?

Re: [PATCH v2 0/4] fix unexpected type conversions and potential overflows

[Andrew Morton]

On Wed, 25 Mar 2026 16:57:16 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:

> I'm inclined to mark this "don't care".  But if we decide to backport
> [2/4] ("to prevent potential overflow issues") then we might have a
> problem.
> 
> Also, if some downstream person decides to backport [2/4] into their
> kernel without [4/4] then they'll have a bad day.
> 
> So perhaps this issue should be addressed within [2/4]?

Actually I can trivially do this locally if you like - just turn [4/4]
into a -fix patch against [2/4], squash them together later on.

Please lmk if you'd like me to do that.

Re: [PATCH v2 0/4] fix unexpected type conversions and potential overflows

[Qi Zheng]

On 3/26/26 7:57 AM, Andrew Morton wrote:
> On Wed, 25 Mar 2026 22:13:21 +0800 Qi Zheng <qi.zheng@linux.dev> wrote:
> 
>> As Harry Yoo pointed out [1], in scenarios where massive state updates occur
>> (e.g., during the reparenting of LRU folios), the values passed to memcg stat
>> update functions can accumulate and exceed the upper limit of a 32-bit integer.
>>
>> If the parameter types are not large enough (like 'int') or are handled
>> incorrectly, it can lead to severe truncation, potential overflow issues,
>> and unexpected type conversion bugs.
>>
>> This series aims to address these issues by correcting the parameter types
>> in the relevant functions, and fixing an implicit conversion bug in
>> memcg_state_val_in_pages().
> 
> Thanks. I'll add this to mm.git's mm-new branch.
> 
> AI review
> (https://sashiko.dev/#/patchset/cover.1774447069.git.zhengqi.arch%40bytedance.com)
> still points at the problem in [2/4], now describing it as a bisection
> hole.
> 
> In
> https://lkml.kernel.org/r/5fed0611-434c-4fd4-956c-39f23e0459a1@linux.dev
> you said you were going to address this by using abs(), and I see that
> being done in [4/4] so yup, runtime bisection hole.

Right.

> 
> I'm inclined to mark this "don't care".  But if we decide to backport
> [2/4] ("to prevent potential overflow issues") then we might have a
> problem.
> 
> Also, if some downstream person decides to backport [2/4] into their
> kernel without [4/4] then they'll have a bad day.

As Harry Yoo pointed out:

```
Let's look at an example (assuming unit is 1).

val = val * unit = -16384 (-16 KiB)
val * unit / PAGE_SIZE = 0xFFFFFFFFFFFFC000 / PAGE_SIZE = 0x3FFFFFFFFFFFFF
max(0x3FFFFFFFFFFFFF, 1UL) = 0x3FFFFFFFFFF

Yeah, that's a massive positive number.

Hmm but how did it work when it was int?

val = val * unit = -16384 (-16KiB)
val * unit / PAGE_SIZE = 0xFFFFFFFFFFFFC000 / PAGE_SIZE = 0x3FFFFFFFFFFFFF
max(val * unit / PAGE_SIZE, 1UL) = 0x3FFFFFFFFFFFFF
(int)0x3FFFFFFFFFFFFF = 0xFFFFFFFF = (-1)

That's incorrect. It should have been -4?
```

this can already be an issue even without [2/4], and
[2/4] just amplify it.

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

> 
> So perhaps this issue should be addressed within [2/4]?

Because they fix different existing problems, I previously split them
into two patches.

However, since the issues are all quite minor, I feel that combining
them into a single patch is fine.

 >> Actually I can trivially do this locally if you like - just turn [4/4]
i>> nto a -fix patch against [2/4], squash them together later on.
 >>
 >> Please lmk if you'd like me to do that.

That's fine, thank you!

Re: [PATCH v2 0/4] fix unexpected type conversions and potential overflows

[Andrew Morton]

On Thu, 26 Mar 2026 10:30:29 +0800 Qi Zheng <qi.zheng@linux.dev> wrote:

>  >> Actually I can trivially do this locally if you like - just turn [4/4]
> i>> nto a -fix patch against [2/4], squash them together later on.
>  >>
>  >> Please lmk if you'd like me to do that.
> 
> That's fine, thank you!

Done, thanks.

Re: [PATCH v2 0/4] fix unexpected type conversions and potential overflows

[Michal Hocko]

On Wed 25-03-26 22:13:21, Qi Zheng wrote:
> From: Qi Zheng <zhengqi.arch@bytedance.com>
> 
> Hi all,
> 
> As Harry Yoo pointed out [1], in scenarios where massive state updates occur
> (e.g., during the reparenting of LRU folios), the values passed to memcg stat
> update functions can accumulate and exceed the upper limit of a 32-bit integer.

Is this a real problem without reparenting? In other words is this a
follow up for that work or something that we need on its own?
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2 0/4] fix unexpected type conversions and potential overflows

[Harry Yoo (Oracle)]

On Thu, Mar 26, 2026 at 08:14:36AM +0100, Michal Hocko wrote:
> On Wed 25-03-26 22:13:21, Qi Zheng wrote:
> > From: Qi Zheng <zhengqi.arch@bytedance.com>
> > 
> > Hi all,
> > 
> > As Harry Yoo pointed out [1], in scenarios where massive state updates occur
> > (e.g., during the reparenting of LRU folios), the values passed to memcg stat
> > update functions can accumulate and exceed the upper limit of a 32-bit integer.
> 
> Is this a real problem without reparenting? In other words is this a
> follow up for that work or something that we need on its own?

This is not a problem (as discussed in [1]) without reparenting.
[1] https://lore.kernel.org/linux-mm/138d9363-ab0c-4f5c-bedc-b326f5aaee91@linux.dev

-- 
Cheers,
Harry / Hyeonggon

Re: [PATCH v2 0/4] fix unexpected type conversions and potential overflows

[Michal Hocko]

On Thu 26-03-26 16:51:44, Harry Yoo (Oracle) wrote:
> On Thu, Mar 26, 2026 at 08:14:36AM +0100, Michal Hocko wrote:
> > On Wed 25-03-26 22:13:21, Qi Zheng wrote:
> > > From: Qi Zheng <zhengqi.arch@bytedance.com>
> > > 
> > > Hi all,
> > > 
> > > As Harry Yoo pointed out [1], in scenarios where massive state updates occur
> > > (e.g., during the reparenting of LRU folios), the values passed to memcg stat
> > > update functions can accumulate and exceed the upper limit of a 32-bit integer.
> > 
> > Is this a real problem without reparenting? In other words is this a
> > follow up for that work or something that we need on its own?
> 
> This is not a problem (as discussed in [1]) without reparenting.
> [1] https://lore.kernel.org/linux-mm/138d9363-ab0c-4f5c-bedc-b326f5aaee91@linux.dev

Please make it explicit in the changelogs and/or make them part of the
series.

Thanks!
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2 0/4] fix unexpected type conversions and potential overflows

[Lorenzo Stoakes (Oracle)]

On Thu, Mar 26, 2026 at 09:18:10AM +0100, Michal Hocko wrote:
> On Thu 26-03-26 16:51:44, Harry Yoo (Oracle) wrote:
> > On Thu, Mar 26, 2026 at 08:14:36AM +0100, Michal Hocko wrote:
> > > On Wed 25-03-26 22:13:21, Qi Zheng wrote:
> > > > From: Qi Zheng <zhengqi.arch@bytedance.com>
> > > >
> > > > Hi all,
> > > >
> > > > As Harry Yoo pointed out [1], in scenarios where massive state updates occur
> > > > (e.g., during the reparenting of LRU folios), the values passed to memcg stat
> > > > update functions can accumulate and exceed the upper limit of a 32-bit integer.
> > >
> > > Is this a real problem without reparenting? In other words is this a
> > > follow up for that work or something that we need on its own?
> >
> > This is not a problem (as discussed in [1]) without reparenting.
> > [1] https://lore.kernel.org/linux-mm/138d9363-ab0c-4f5c-bedc-b326f5aaee91@linux.dev
>
> Please make it explicit in the changelogs and/or make them part of the
> series.

Agreed!

>
> Thanks!
> --
> Michal Hocko
> SUSE Labs

Cheers, Lorenzo