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

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

[SJ Park]

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@vger.kernel.org> # 5.19.x
Cc: Kunwu Chan <kunwu.chan@gmail.com>
Signed-off-by: SJ Park <sj@kernel.org>
---
Changes from RFC
- RFC: https://lore.kernel.org/20260912200814.145612-5-sj@kernel.org
- 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

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@kernel.org> 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@vger.kernel.org> # 5.19.x
> Cc: Kunwu Chan <kunwu.chan@gmail.com>
> Signed-off-by: SJ Park <sj@kernel.org>

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

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

> ---
> Changes from RFC
> - RFC: https://lore.kernel.org/20260912200814.145612-5-sj@kernel.org
> - 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