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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

New issues:
- [High] Missing zero check for `total` memory in `damos_hugepage_mem_bp()` leads to a potential divide-by-zero kernel panic.
- [Medium] `damos_hugepage_mem_bp()` fails to account for PTE-mapped large folios (mTHPs), leading to inaccurate statistics.

Pre-existing issues:
- [High] Missing zero denominator check for `total` LRU memory in `damos_get_in_active_mem_bp()` causes a divide-by-zero kernel panic.
- [High] Missing zero denominator check in `damos_get_node_mem_bp()` and `damos_get_node_memcg_used_bp()` can cause a divide-by-zero kernel panic.
--

commit 93cbe76d8ef461360b9dc14ac3328663e6ee8602
Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>

mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning

This commit introduces DAMOS_QUOTA_HUGEPAGE_MEM_BP auto tuning. It adds
a new DAMOS quota goal metric to measure the amount of huge page
consumption to total memory consumption ratio.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 7e4b9affc5b06..b001f80681b12 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -2795,6 +2795,17 @@ static unsigned int damos_get_in_active_mem_bp(bool active_ratio)
>  	return mult_frac(inactive, 10000, total);

[Severity: High]
This is a pre-existing issue, but can this lead to a divide-by-zero panic?

If a system or node has no evictable pages (for example, in constrained
environments with only kernel slab allocations or purely unevictable/mlocked
workloads), active and inactive LRU counts will both be 0. 

Could total be evaluated as 0 here, causing mult_frac() to trigger an
unconditional divide-by-zero kernel panic?

>  }
>  
> +static unsigned int damos_hugepage_mem_bp(void)
> +{
> +	unsigned long thp, total;
> +
> +	thp = global_node_page_state(NR_ANON_THPS) +
> +				global_node_page_state(NR_SHMEM_THPS) +
> +				global_node_page_state(NR_FILE_THPS);

[Severity: Medium]
Does this calculation miss PTE-mapped large folios (mTHPs)?

These vmstat counters only track PMD-mapped transparent huge pages. They
do not track PTE-mapped multi-size THPs (mTHPs), which increment separate
counters such as MTHP_STAT_NR_ANON. 

Since modern kernels increasingly use mTHPs, will DAMON's quota
auto-tuning underestimate the actual huge page consumption here?

> +	total = totalram_pages() - global_zone_page_state(NR_FREE_PAGES);
> +	return mult_frac(thp, 10000, total);

[Severity: High]
Could total evaluate to zero here and cause a divide-by-zero panic?

If all managed memory on the system is free (e.g., in a specialized idle
state) or if per-CPU counter drift causes
global_zone_page_state(NR_FREE_PAGES) to momentarily equal
totalram_pages(), total will evaluate to exactly 0. 

Since mult_frac() performs standard division without internal zero
checks, could this trigger a hardware divide-by-zero exception and crash
the kernel?

> +}

While reviewing the LRU metric above, I noticed a similar pattern in
other DAMOS metric calculations:

mm/damon/core.c:damos_get_node_mem_bp() {
    ...
    si_meminfo_node(&i, goal->nid);
    ...
    return mult_frac(numerator, 10000, i.totalram);
}

[Severity: High]
This isn't a bug introduced by this patch, but does this code also suffer
from a missing zero denominator check?

damos_get_node_mem_bp() and damos_get_node_memcg_used_bp() filter valid
nodes via !node_state(nid, N_MEMORY), but N_MEMORY only guarantees the
presence of physical memory, not managed buddy pages.

If all physical memory on a node is reserved (such as memblock
reservations or crashkernel), managed_pages will be exactly 0, which
means i.totalram populated by si_meminfo_node() will be 0. 

Could this result in a divide-by-zero panic when evaluated by
mult_frac()?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260619145821.2109933-1-gutierrez.asier@huawei-partners.com?part=1