All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Liew Rui Yan" <aethernet65535@gmail.com>
Cc: damon@lists.linux.dev
Subject: Re: [PATCH v2.1] mm/damon/core: fix false positive in damos_quota_is_full() when esz is zero
Date: Wed, 02 Sep 2026 08:53:35 +0000	[thread overview]
Message-ID: <20260902085336.6F0B91F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260902084445.27170-1-aethernet65535@gmail.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Schemes without configured quota limits (unlimited quotas) are completely skipped and never applied due to the new `!quota->esz` early exit check.
- [Medium] Incorrect quota evaluation for very small quotas (`0 < esz < min_region_sz`) breaks the early short-circuit optimization, causing wasted CPU cycles, artificially inflated statistics, and broken telemetry.
--

commit 4718f859e447852ff19b6830ab8bf79106ad37d1
Author: Liew Rui Yan <aethernet65535@gmail.com>
Subject: mm/damon/core: fix false positive in damos_quota_is_full() when esz is zero

This patch aims to fix an issue where damos_quota_is_full() returns true when
quota->esz_bp drops to zero, even if no regions have been tried. It attempts
to resolve this by adding early checks for zero quota->charged_sz and
zero quota->esz.

Cc: <stable@vger.kernel.org> # v7.2.x

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index df22621765911..f8c784df24600 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -2655,6 +2655,8 @@ static bool damos_quota_is_full(struct damos_quota *quota,
>  {
>  	if (!damos_quota_is_set(quota))
>  		return false;
> +	if (!quota->charged_sz)
> +		return false;

[Severity: Medium]
Could this cause an evaluation loop that degrades performance when the
configured quota is very small?

If a quota is configured such that 0 < quota->esz < min_region_sz,
quota->charged_sz starts at 0 at the beginning of the quota window.
This new check will return false, bypassing the subsequent small remaining
quota check:

    return quota->esz - quota->charged_sz < min_region_sz;

This falsely signals available quota. Later, when damon_do_apply_schemes()
calls damos_apply_scheme(), the size is calculated as:

    sz = ALIGN_DOWN(quota->esz - quota->charged_sz, c->min_region_sz);

Because esz < min_region_sz and charged_sz is 0, sz evaluates to 0. The code
then jumps to update_stat, which increments nr_tried but does not increase
charged_sz.

Since charged_sz remains 0, the next region will also evaluate to 0 and skip
charging. Won't this loop wastefully over every region in an O(N) fashion,
artificially inflating the nr_tried statistics and breaking the qt_exceeds
telemetry?

>  	if (quota->charged_sz >= quota->esz)
>  		return true;
>  	/*
> @@ -2750,6 +2752,9 @@ static void damon_do_apply_schemes(struct damon_ctx *c,
>  		if (!s->wmarks.activated)
>  			continue;
>  
> +		if (!quota->esz)
> +			continue;
> +

[Severity: High]
Does this unconditional check completely skip schemes that do not have quota
limits configured?

For unlimited schemes (schemes without configured quotas), damos_adjust_quota()
returns early without calculating esz, leaving quota->esz initialized to 0.
With this check, won't unlimited schemes silently fail to apply entirely
because the loop unconditionally continues?

>  		/* Check the quota */
>  		if (damos_quota_is_full(quota, c->min_region_sz))
>  			continue;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902084445.27170-1-aethernet65535@gmail.com?part=1

  reply	other threads:[~2026-09-02  8:53 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02  8:44 [PATCH v2.1] mm/damon/core: fix false positive in damos_quota_is_full() when esz is zero Liew Rui Yan
2026-09-02  8:53 ` sashiko-bot [this message]
2026-09-02  9:42   ` Liew Rui Yan
2026-09-02 14:10 ` SJ Park
2026-09-02 14:22   ` Liew Rui Yan
2026-09-02 14:48     ` SJ Park
2026-09-02 22:31       ` Liew Rui Yan
2026-09-03  0:33         ` SJ Park
2026-09-03 12:41           ` Liew Rui Yan
2026-09-03 14:05             ` SJ Park
2026-09-04  8:07               ` Liew Rui Yan
2026-09-04 14:05                 ` SJ Park
2026-09-04 15:35                   ` Liew Rui Yan
2026-09-05  0:25                     ` SJ Park
2026-09-05 10:36                       ` Liew Rui Yan
2026-09-05 16:12                         ` SJ Park
2026-09-06 22:25                           ` Liew Rui Yan
2026-09-07 16:33                             ` SJ Park

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260902085336.6F0B91F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=aethernet65535@gmail.com \
    --cc=damon@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.