DAMON development mailing list
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "SJ Park" <sj@kernel.org>
Cc: damon@lists.linux.dev
Subject: Re: [RFC PATCH 1/9] mm/damon/core: skip applying scheme if region split for quota fails
Date: Sat, 01 Aug 2026 17:53:34 +0000	[thread overview]
Message-ID: <20260801175335.2D7E21F00AC4@smtp.kernel.org> (raw)
In-Reply-To: <20260801173554.94710-2-sj@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Unhandled failure of damon_split_region_at() in damos_filter_match() leads to bypassing or incorrectly applying address filters.
--

--- Patch [1]: [RFC PATCH 1/9] mm/damon/core: skip applying scheme if region split for quota fails ---
commit 812934b542c69c596afadb66403f8c9c11c5bf91
Author: SJ Park <sj@kernel.org>

mm/damon/core: skip applying scheme if region split for quota fails

damos_apply_scheme() splits a region and apply the action to the
subregion if it is needed for not violating the quota.  The split
operation (damon_split_region_at()) could fail for allocation failure.
In the case, the quota could be violated.  From the user's perspective,
DAMOS becomes more aggressive than expected under the extreme situation.
Handle the failure.

Link: https://lore.kernel.org/20260718171523.87547-1-sj@kernel.org

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 644daf5a16560..e2900d0c984c9 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -2613,7 +2613,8 @@ static void damos_apply_scheme(struct damon_ctx *c, struct damon_target *t,
>  					c->min_region_sz);
>  			if (!sz)
>  				goto update_stat;
> -			damon_split_region_at(t, r, sz);
> +			if (damon_split_region_at(t, r, sz))
> +				goto update_stat;

[Severity: High]
This is a pre-existing issue, but since we are handling the failure of
damon_split_region_at() here, should we also handle it in
damos_filter_match()?

If a memory region partially overlaps a filter range and the split
allocation fails in damos_filter_match(), the return value is ignored:

mm/damon/core.c:damos_filter_match() {
    ...
		/* start before the range and overlap */
		if (r->ar.start < start) {
			damon_split_region_at(t, r, start - r->ar.start);
			matched = false;
			break;
		}
		/* start inside the range */
		damon_split_region_at(t, r, end - r->ar.start);
		matched = true;
		break;
    ...
}

If the split fails, the intact region spanning both outside and inside the
filter range is unconditionally evaluated as 'matched = false' or
'matched = true', incorrectly bypassing the filter or applying it to unrelated
memory outside the intended range.

Could this lead to destructive actions (e.g., PAGEOUT) being applied to
explicitly protected memory?

>  		}
>  		if (damos_core_filter_out(c, t, r, s))
>  			return;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260801173554.94710-1-sj@kernel.org?part=1

  reply	other threads:[~2026-08-01 17:53 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-01 17:35 [RFC PATCH 0/9] mm/damon: fix DAMOS bugs in core, paddr and vaddr SJ Park
2026-08-01 17:35 ` [RFC PATCH 1/9] mm/damon/core: skip applying scheme if region split for quota fails SJ Park
2026-08-01 17:53   ` sashiko-bot [this message]
2026-08-01 20:01     ` SJ Park
2026-08-01 20:31       ` SJ Park
2026-08-01 17:35 ` [RFC PATCH 2/9] mm/damon/core: initialize damos_quota_goal->last_psi_total SJ Park
2026-08-01 17:35 ` [RFC PATCH 3/9] mm/damon/paddr: respect folio end for DAMOS_STAT SJ Park
2026-08-01 18:21   ` sashiko-bot
2026-08-01 20:07     ` SJ Park
2026-08-01 17:35 ` [RFC PATCH 4/9] mm/damon/paddr: respect folio end for DAMOS actions except STAT SJ Park
2026-08-01 17:35 ` [RFC PATCH 5/9] mm/damon/vaddr: respect folio end for DAMOS_STAT SJ Park
2026-08-01 18:50   ` sashiko-bot
2026-08-01 20:12     ` SJ Park
2026-08-01 17:35 ` [RFC PATCH 6/9] mm/damon/vaddr: respect folio end for DAMOS_MIGRATE_{HOT,COLD} SJ Park
2026-08-01 17:35 ` [RFC PATCH 7/9] mm/damon/core: handle extreme memory state in damon_get_node_mem_bp() SJ Park
2026-08-01 19:11   ` sashiko-bot
2026-08-01 20:18     ` SJ Park
2026-08-01 17:35 ` [RFC PATCH 8/9] mm/damon/core: handle extreme memory state in get_node_memcg_used_bp() SJ Park
2026-08-01 19:31   ` sashiko-bot
2026-08-01 20:26     ` SJ Park
2026-08-01 17:35 ` [RFC PATCH 9/9] mm/damon/core: handle extreme memory state in get_in_active_mem_bp() SJ Park
2026-08-01 19:39   ` sashiko-bot
2026-08-01 20:29     ` 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=20260801175335.2D7E21F00AC4@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=damon@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sj@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox