Re: [RFC PATCH v2] mm/damon/core: don't skip damos_adjust_quota() while esz is not zero

[KunWu Chan]

On Wed, Sep 16, 2026 at 12:14 PM SJ Park <sj@xxxxxxxxxx> wrote:
>
> DAMOS could unexpectedly stop working when a user disables quota using
> the online parameters commit feature.  Fix it by correcting a wrong
> quota unset check in damos_adjust_quota().
>
> DAMON users could disable all quotas by unsetting time and size quotas,
> and removing all quota goals.  The intention of disabling quotas would
> be making DAMOS run at full speed.  When such quota disabled setup is
> detected, damos_adjust_quota() skips all its work.  The skipped works
> include effective size quota (damos_quota->esz) updates and charged
> quota amount (damos_quota->charged_sz) resets.  The intention is to
> avoid doing unnecessary work when quotas are disabled.
>
> However, users could do the setup while effective size quota is
> non-zero, by doing the disabling with the online DAMON parameters commit
> feature.  In this case, because the effective size quota exists, DAMOS
> will keep working with the quota until it is fully charged.  After the
> effective quota is fully charged, the charged quota amount
> (damos_quota->charged_sz) cannot be reset because damos_adjust_quota()
> skips it.  Then, DAMOS stops working until the quota is newly set or
> DAMON is entirely restarted.
>
> The problem happens because damos_adjust_quota() assumes the user setup
> for disabling quota immediately disabled it.  In reality, the quota is
> still working until the effective size quota is also updated to zero.
> Other logic for catching that uses damos_quota_is_set(), which
> understands the fact and therefore checks the effective size quota in
> addition to the user setup.  Fix the issue by using damos_quota_is_set()
> in damos_adjust_quota() to determine if its works should be skipped.
>
> The user impact is a non-deterministic and unexpected DAMOS stop
> behavior.  That is, users would disable quotas using the online
> parameters commit feature, expecting DAMOS will run at full speed.
> However, depending on the timing, the setup can be updated while the
> effective size quota is non-zero.  Due to the above mentioned internal
> mechanism, DAMOS stops working instead of running at full speed.  It is
> unexpected behavior.  It is also non-deterministic because sometimes the
> setup is done when the effective size quota is zero, depending on the
> timing.  It doesn't cause critical issues like crashes or leaks.  Users
> can simply set a reasonable quota again, or restart DAMON.  But
> definitely it is an unexpected and non-deterministic behavior that makes
> it difficult to reliably use.  Also investigating the root cause of the
> behavior would be quite difficult.
>
> Fixes: da87878010e5 ("mm/damon/sysfs: support online inputs update")
> Cc: <stable@xxxxxxxxxxxxxxx> # 5.19.x
> Cc: Kunwu Chan <kunwu.chan@xxxxxxxxx>
> Signed-off-by: SJ Park <sj@xxxxxxxxxx>

Thanks, SJ. The commit message captures the full lifecycle precisely.

Reviewed-by: Kunwu Chan <kunwu.chan@xxxxxxxxx>

> ---
> Changes from RFC
> - RFC: https://lore.kernel.org/20260912200814.145612-5-sj@xxxxxxxxxx
> - Split out from the cleanup series for taking hotfix path.
> - Describe the real issue.
>
>  mm/damon/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index e0414d2adcb41..89390897a0d8e 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -3330,7 +3330,7 @@ static void damos_adjust_quota(struct damon_ctx *c, struct damos *s)
>         unsigned long cumulated_sz, cached_esz;
>         unsigned int score, max_score = 0;
>
> -       if (!quota->ms && !quota->sz && list_empty(&quota->goals))
> +       if (!damos_quota_is_set(quota))
>                 return;
>
>         /* First charge window */
>
> base-commit: 191c4a84eef1db85cc7e1a853761e8ce8683afd4
> --
> 2.47.3