Re: [PATCH v4 1/3] mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Unbounded metric calculation due to vmstat drift can destabilize quota tuning.
- [High] Silent 32-bit integer overflow in `mult_frac()` during memory ratio calculation.
--

commit 59f2c739bce03363ce501965d6708d807908af18
Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
Date:   Mon Aug 31 14:47:28 2026 +0000

mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning

This commit introduces a new DAMOS quota goal metric,
DAMOS_QUOTA_HUGEPAGE_MEM_BP, to auto-tune quotas based on the ratio of huge
page consumption to total memory consumption. It includes a fallback
mechanism for situations where vmstat counters drift and report more free
pages than total RAM.

Link: https://lore.kernel.org/all/20260715151615.99767-1-sj@kernel.org/

[ ... ]

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 644daf5a16560..9c0e42a1d2cfc 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c

[ ... ]

> @@ -3007,6 +3007,22 @@ static unsigned int damos_get_in_active_mem_bp(bool active_ratio)
>  	return mult_frac(inactive, 10000, total);
>  }
>  
> +static unsigned int damos_hugepage_mem_bp(void)
> +{
> +	unsigned long thp, total_pages, free_pages;
> +
> +	total_pages = totalram_pages();
> +	free_pages = global_zone_page_state(NR_FREE_PAGES);
> +
> +	if (total_pages <= free_pages)
> +		return 10000;
> +
> +	thp = global_node_page_state(NR_ANON_THPS) +
> +				global_node_page_state(NR_SHMEM_THPS) +
> +				global_node_page_state(NR_FILE_THPS);
> +	return mult_frac(thp, 10000, total_pages - free_pages);

[Severity: High]
Could the independent vmstat counters drift enough to produce an
out-of-bounds ratio here?

Because NR_ANON_THPS, NR_SHMEM_THPS, NR_FILE_THPS, and NR_FREE_PAGES are
updated asynchronously across CPUs, they can drift in opposite directions.
On systems with high core counts, if the system's actual used memory is
low but the thp stat artificially drifts higher than the calculated used
memory (or used memory drifts toward zero), the calculated ratio could
vastly exceed 10,000 (100%).

Would this cause the DAMOS auto-tuning PID controller to calculate an
exponentially inflated goal score, ultimately crushing the tuning quota to
zero and paralyzing DAMON's actions?

[Severity: High]
Can this calculation silently overflow on 32-bit architectures?

The mult_frac macro evaluates an intermediate multiplication that retains
the 32-bit type of x. Both thp and total_pages are declared as unsigned
long.

On 32-bit architectures like ARM32 with LPAE (which supports Transparent
Hugepages and up to 1TB RAM), unsigned long is 32 bits. If THP consumption
exceeds 429,496 base pages (around 1.71 GB), the intermediate calculation
(thp * 10000) will wrap around U32_MAX.

For example, 2GB of THP on a 3GB system might falsely report a 9.4% ratio
instead of 66.6%. Will this cause DAMON to mis-tune memory limits due to a
highly truncated quota goal metric?

> +}
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831144732.80910-1-sj@kernel.org?part=1