Re: [RFC PATCH v1 2/4] 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:
- [Critical] Divide-by-zero panic in damos_get_used_hugepage_mem_bp() when no anonymous memory is mapped.
- [Medium] Missing sysfs string mapping for DAMOS_QUOTA_HUGEPAGE renders the metric unconfigurable via userspace.
--

commit 46bdbb5e7c05e4c06aea38af1c50ac5407f8b9c3
Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>

mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning

Introduce DAMOS_QUOTA_HUGEPAGE auto tuning Add a new DAMOS quota goal
metric to measure the amount of huge page consumption to total anonymous
memory consumption ratio.

> diff --git a/include/linux/damon.h b/include/linux/damon.h
> index 143d024fec845..ee937b3892c68 100644
> --- a/include/linux/damon.h
> +++ b/include/linux/damon.h
> @@ -174,6 +174,7 @@ enum damos_quota_goal_metric {
>  	DAMOS_QUOTA_NODE_MEMCG_FREE_BP,
>  	DAMOS_QUOTA_ACTIVE_MEM_BP,
>  	DAMOS_QUOTA_INACTIVE_MEM_BP,
> +	DAMOS_QUOTA_HUGEPAGE,

Is there a missing update to the string mapping array in sysfs for this new
metric?

If damos_sysfs_qgoal_metric_names in mm/damon/sysfs-schemes.c isn't updated
to include DAMOS_QUOTA_HUGEPAGE, wouldn't configuring this metric from
userspace fail and return -EINVAL?

>  	NR_DAMOS_QUOTA_GOAL_METRICS,
>  };

[ ... ]

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 1af84e0ac1dd4..63cbf30288d53 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c

[ ... ]

> @@ -2320,6 +2320,18 @@ static unsigned int damos_get_in_active_mem_bp(bool active_ratio)
>  	return mult_frac(inactive, 10000, total);
>  }
>  
> +/*
> + * Returns anon hugepage memory to total anon memory use ratio.
> + */
> +static unsigned int damos_get_used_hugepage_mem_bp(void)
> +{
> +	unsigned long used_hugepages, total_used;
> +
> +	used_hugepages = global_node_page_state(NR_ANON_THPS);
> +	total_used = global_node_page_state(NR_ANON_MAPPED);
> +	return mult_frac(used_hugepages, 10000, total_used);

Can total_used be zero here?

If there is no anonymous memory mapped in the system (for example, right
after boot or on a system running purely file-backed workloads), total_used
would evaluate to 0.

Since mult_frac() directly performs division and modulo without
zero-checking the denominator, wouldn't passing 0 as total_used trigger a
divide-by-zero exception and crash the kernel?

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