Re: [RFC PATCH v1.1 9/9] mm/damon/core: handle extreme memory state in get_in_active_mem_bp()

[SJ Park <sj@kernel.org>]

On Sun, 02 Aug 2026 16:51:05 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] 32-bit integer overflows and truncations in DAMON memory metric calculations cause wildly incorrect quota logic on 32-bit architectures.
> --
> 
> --- Patch [9]: [RFC PATCH v1.1 9/9] mm/damon/core: handle extreme memory state in get_in_active_mem_bp() ---
> commit e72445b8d3c8d0866c458b7707c7433d7912c2e6
> Author: SJ Park <sj@kernel.org>
> 
> mm/damon/core: handle extreme memory state in get_in_active_mem_bp()
> 
> This commit addresses a divide-by-zero issue in damos_get_in_active_mem_bp().
> It ensures the denominator is at least 1 when calculating the ratio of
> active or inactive memory, preventing a crash if both are zero.
> 
> Link: https://lore.kernel.org/20260721034756.147011-1-sj@kernel.org
> 
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > index 67ad1f07c29a4..c79b854e1a971 100644
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> > @@ -3014,7 +3014,7 @@ static unsigned int damos_get_in_active_mem_bp(bool active_ratio)
> >  		global_node_page_state(NR_LRU_BASE + LRU_ACTIVE_FILE);
> >  	inactive = global_node_page_state(NR_LRU_BASE + LRU_INACTIVE_ANON) +
> >  		global_node_page_state(NR_LRU_BASE + LRU_INACTIVE_FILE);
> > -	total = active + inactive;
> > +	total = max(active + inactive, 1);
> >  	if (active_ratio)
> 
> [Severity: High]
> This is a pre-existing issue, but does this code overflow 32-bit unsigned
> math on 32-bit architectures?
> 
> The mult_frac(x, n, d) macro computes (x / d) * n + (x % d) * n / d. Since
> n is 10000, the multiplication x * 10000 is performed using 32-bit unsigned
> arithmetic on 32-bit systems (where unsigned long is 32 bits). If active
> memory exceeds 429,496 pages (~1.76 GB), the multiplication overflows
> ULONG_MAX, resulting in an incorrect ratio.
> 
> Does this same overflow also affect other DAMON memory metric calculations?
> For example, in damos_get_node_eligible_mem_bp():
> 
>     return mult_frac((unsigned long)node_eligible, 10000,
>                      (unsigned long)total_eligible);
> 
> This explicitly casts a 64-bit phys_addr_t to unsigned long, truncating
> capacities over 4GB on 32-bit systems. It also overflows mult_frac() if the
> eligible memory exceeds just ~419 KB.
> 
> Similarly, in damon_get_intervals_score():
> 
>     max_access_events += sz_region * c->attrs.aggr_samples;
>     access_events += sz_region * r->nr_accesses;
> 
> Because sz_region is in bytes, accumulating these into an unsigned long
> seems to overflow for regions larger than a few tens of megabytes.

Known low priority issue.

> 
> >  		return mult_frac(active, 10000, total);
> >  	return mult_frac(inactive, 10000, total);
> >  }
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260802162631.90304-1-sj@kernel.org?part=9
> 


Thanks,
SJ