Re: [RFC PATCH v3 1/4] mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning

[SeongJae Park <sj@kernel.org>]

On Fri, 5 Jun 2026 13:57:47 +0300 Gutierrez Asier <gutierrez.asier@huawei-partners.com> wrote:

> 
> 
> On 6/4/2026 6:19 PM, sashiko-bot@kernel.org wrote:
[...]
> > [Severity: High]
> > This is a pre-existing issue, but can this cause a divide by zero kernel
> > panic?
> > 
> > If there are no active or inactive pages, or if per-CPU vmstat counter drift
> > evaluates total to 0, mult_frac() will divide by zero.
> Not a bug. The system can never have 0 consumed memory.

Makes sense.

> >> +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);
> >> +	total = totalram_pages() - global_zone_page_state(NR_FREE_PAGES);
> >> +	return mult_frac(thp, 10000, total);
> > 
> > [Severity: High]
> > Can mult_frac() divide by zero here?
> > 
> > If the system is highly idle or due to per-CPU vmstat counter drift, total
> > could evaluate to exactly 0.
> No, total can never be 0.
> > [Severity: Medium]
> > Is there a risk of a 32-bit overflow in this calculation?
> > 
> > On 32-bit architectures, mult_frac() preserves types, and computing
> > thp * 10000 could exceed the maximum unsigned long value if there are
> > more than ~1.7 GB of THPs, producing an arbitrarily small quota target.
> > 
> Good catch! I will cast 10000 to unsigned long to preserve the types.

But still it is 'unsigned long' that has only 32 bits on 32-bit architectures?
So it shouldn't make any change here.  Or, am I missing something?


Thanks,
SJ

[...]