Re: [RFC PATCH 1/9] mm/damon/core: skip applying scheme if region split for quota fails

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 regio=
n split for quota fails ---
commit 812934b542c69c596afadb66403f8c9c11c5bf91
Author: SJ Park <[email protected]>

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/[email protected]

> 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 =3D false;
			break;
		}
		/* start inside the range */
		damon_split_region_at(t, r, end - r->ar.start);
		matched =3D true;
		break;
    ...
}

If the split fails, the intact region spanning both outside and inside the
filter range is unconditionally evaluated as 'matched =3D false' or
'matched =3D true', incorrectly bypassing the filter or applying it to unre=
lated
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;

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260801173554.9471=
[email protected]?part=3D1