Re: [PATCH v1 3/3] mm/damon/sysfs: support hugepage_mem_bp quota goal metric

[SeongJae Park <sj@kernel.org>]

On Tue, 16 Jun 2026 22:35:21 +0300 Gutierrez Asier <gutierrez.asier@huawei-partners.com> wrote:

> 
> 
> On 6/16/2026 6:21 PM, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> > 
> > New issues:
> > - [Low] The new `DAMOS_QUOTA_HUGEPAGE_MEM_BP` metric is exposed via sysfs but lacks required documentation updates.
> > 
> > Pre-existing issues:
> > - [Critical] Potential divide-by-zero in `damos_hugepage_mem_bp()` and `damos_get_in_active_mem_bp()` due to an unhandled zero denominator.
> > - [High] 32-bit integer overflow in `damos_hugepage_mem_bp()` and `damos_get_in_active_mem_bp()` when calculating memory ratios.
> > --
> > 
> > commit be304699fb94d4d73bd979237fb4d7b08b7216f7
> > Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> > 
> > mm/damon/sysfs: support hugepage_mem_bp quota goal metric
> > 
> > DAMOS has a new autotune policy metric: DAMOS_QUOTA_HUGEPAGE_MEM_BP.
> > This patch exposes DAMOS_QUOTA_HUGEPAGE_MEM_BP through sysfs.
> > 
> >> diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
> >> index 329cfd0bbe9f3..4b5429a5b4158 100644
> >> --- a/mm/damon/sysfs-schemes.c
> >> +++ b/mm/damon/sysfs-schemes.c
> >> @@ -1267,6 +1267,10 @@ struct damos_sysfs_qgoal_metric_name damos_sysfs_qgoal_metric_names[] = {
> >>  		.metric = DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP,
> >>  		.name = "node_eligible_mem_bp",
> >>  	},
> >> +	{
> >> +		.metric = DAMOS_QUOTA_HUGEPAGE_MEM_BP,
> >> +		.name = "hugepage_mem_bp",
> >> +	},
> > 
> > [Severity: Critical]
> > This isn't a bug introduced by this patch, but exposing this metric directly
> > to userspace makes a potential divide-by-zero triggerable by users
> > configuring DAMON quotas.
> > 
> > In mm/damon/core.c:damos_hugepage_mem_bp(), the denominator is computed as:
> > 
> >     total = totalram_pages() - global_zone_page_state(NR_FREE_PAGES);
> > 
> > Due to per-CPU vmstat lag or an idle system, the free pages counter can equal
> > totalram_pages(), resulting in total being 0. This is then passed to
> > mult_frac():
> > 
> >     return mult_frac(thp, 10000, total);
> > 
> > This inherently computes thp / total, causing a strict division by zero and a
> > kernel panic. The same issue exists in damos_get_in_active_mem_bp() where
> > total = active + inactive, which can be 0 if the LRU lists are empty.
> > 
> > Should a zero-check on total be added before performing the division?
> DAMON is enabled after the system is fully loaded. total will not be 0 by then.

Could you please further clarify what "system is fully loaded" means, reaards
to what Sashiko is claiming, particularly the per-CPU vmstat lag?


Thanks,
SJ

[...]