Re: [PATCH 6.6.y] mm/damon/core: disallow time-quota setting zero esz

[SeongJae Park <sj@kernel.org>]

On Mon, 04 May 2026 14:26:22 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Integer overflow in throughput estimation permanently breaks DAMOS time quota mechanism.

Mild issue that not an issue for this patch.  Read below for more details.

> --
> 
> commit 352051c643d14056b79b910e005f54b4d071e250
> Author: SeongJae Park <sj@kernel.org>
> 
> mm/damon/core: disallow time-quota setting zero esz
> 
> This patch fixes an issue where a slow DAMOS scheme causes the effective size
> quota to fall below the minimum region size, which prevents actions from being
> applied. Because no actions are applied, the charge statistics stop updating
> and the scheme is unexpectedly deactivated. The fix ensures the effective size
> quota is always clamped to at least the minimum region size.
> 
> Link: https://lore.kernel.org/20260407003153.79589-1-sj@kernel.org
> Link: https://lore.kernel.org/20260405192504.110014-1-sj@kernel.org [1]
> 
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > index 48747236c21c..12c2e584659a 100644
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> > @@ -1026,6 +1026,7 @@ static void damos_set_effective_quota(struct damos_quota *quota)
> >  	else
> >  		throughput = PAGE_SIZE * 1024;
> >  	esz = throughput * quota->ms;
> 
> Since total_charged_sz accumulates lifetime processed bytes without being
> reset, can the throughput calculation that precedes this line cause a
> regression by overflowing?
> 
> In damos_set_effective_quota(), throughput is calculated as:
> throughput = quota->total_charged_sz * 1000000 / quota->total_charged_ns;
> 
> On 32-bit architectures, total_charged_sz * 1000000 would overflow when
> total_charged_sz reaches just 4295 bytes. On 64-bit architectures, it would
> overflow after about 18.44 TB of memory processed.
> 
> Once total_charged_sz * 1000000 wraps around, the numerator becomes extremely
> small compared to the denominator (which on 64-bit takes 584 years to wrap),
> causing the computed throughput to instantly drop to near zero.
> 
> > +	esz = max(DAMON_MIN_REGION, esz);
> 
> Although this clamping ensures esz never drops below DAMON_MIN_REGION, would
> the scheme become permanently throttled down to this minimum region size
> until the numerator catches up again after another 18 TB of processing?

Not this patch's fault.  The user impact should also be trivial.  Please refer
to my previous answer [1] to the similar Sashiko question.

[1] https://lore.kernel.org/20260505150012.29007-1-sj@kernel.org


Thanks,
SJ

[...]