Re: [RFC PATCH v3 2/4] mm/damon: fix esz=0 quota bypass allowing unlimited migration

[SeongJae Park <sj@kernel.org>]

On Wed, 25 Feb 2026 10:28:30 -0800 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:

> On Mon, Feb 23, 2026 at 5:54 PM SeongJae Park <sj@kernel.org> wrote:
> >
> > On Mon, 23 Feb 2026 12:32:30 +0000 Ravi Jonnalagadda <ravis.opensrc@gmail.com> wrote:
> >
> > > When the TEMPORAL goal tuner sets esz_bp=0 to signal that a goal has
> > > been achieved, the quota check was not actually stopping migration.
> > >
> > > The condition:
> > >     if (quota->esz && quota->charged_sz >= quota->esz)
> > >
> > > When esz=0, this evaluates to (false && ...) = false, so the continue
> > > is never executed and migration proceeds without limit.
> >
> > Nice finding, thank you for sharing this!
> 
> Thanks!
> 
> >
> > >
> > > Change the logic to:
> > >     if (!quota->esz || quota->charged_sz >= quota->esz)
> > >
> > > Now when esz=0, (!0 = true) causes the continue to execute, properly
> > > stopping migration when the goal is achieved.
> >
> > But this code is written in the way because the current code assumes zero 'esz'
> > means it is not being used and therefore be ignored.  This change should be ok
> > for your use case, but could introduce an unexpected behavioral change for
> > other users.
> >
> > One easy workaround would be setting esz_bp with a value smaller than 40960000
> > instead of 0.  That is, esz_bp is the bytes in bp, so setting it smaller than
> > 40960000 will result in making it effectively zero, e.g., like below.
> >
> > '''
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> > @@ -2623,7 +2623,7 @@ static void damos_goal_tune_esz_bp_temporal(struct damos_quota *quota)
> >         unsigned long score = damos_quota_score(quota);
> >
> >         if (score >= 10000)
> > -               quota->esz_bp = 0;
> > +               quota->esz_bp = 10000;
> >         else if (quota->sz)
> >                 quota->esz_bp = quota->sz * 10000;
> >         else
> > '''
> >
> > But maybe there is a better way to cleanly fix this.  Let me take a time to
> > think more...
> >
> 
> I understand. Please take your time. I'm happy to test whatever approach
> you come up with.

Thank you for being flexible, I will do!


Thanks,
SJ

[...]