[PATCH 1/7] mm/damon/core: initialize damos->last_applied

[SJ Park]

Multiple DAMON regions could exist across a folio. If they fulfill the
condition to apply a DAMOS scheme, the scheme could be applied multiple
times to the folio. To avoid this, each DAMOS scheme stores the folio
that the scheme was applied to last time in the damos->last_applied
field and skips repeatedly applying the same scheme to the same folio.

The field is being used without initialization, though. Hence, the
mechanism could wrongly skip applying a scheme to a folio at the very
first time of DAMOS run.

The user impact is trivial. DAMON might unexpectedly skip applying
DAMOS action for one folio for the first time per scheme. In the
DAMON's best-effort world, this is never a real problem. No critical
consequences such as kernel panic or memory corruption happen.

It is a clear bug, though, and the fix is straightforward. Fix the
issue by initializing the field in DAMOS scheme creation function,
damon_new_scheme().

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/2026071405543...@kernel.org

Fixes: 94ba17adaba0 ("mm/damon: avoid applying DAMOS action to same entity multiple times")
Cc: <sta...@vger.kernel.org> # 6.15.x
Signed-off-by: SJ Park <s...@kernel.org>
---
mm/damon/core.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/mm/damon/core.c b/mm/damon/core.c
index f464b4f0976c3..60255f5cd715e 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -705,6 +705,7 @@ struct damos *damon_new_scheme(struct damos_access_pattern *pattern,
INIT_LIST_HEAD(&scheme->ops_filters);
scheme->stat = (struct damos_stat){};
scheme->max_nr_snapshots = 0;
+ scheme->last_applied = NULL;
INIT_LIST_HEAD(&scheme->list);

scheme->quota = *(damos_quota_init(quota));
--
2.47.3

[SJ Park]

Fix a few Sashiko-found unurgent bugs. Patch 1 fixes use of
uninitialized damos->last_applied field. Patches 2-7 fix DAMON kunit
tests that do invalid memory access under test failures.

The bugs are better to be fixed and eventually merged into stable@
kernel. That said, the fixes are arguably not urgent. Patch 1 only
introduces negligible DAMOS efficiency degradation in occasional
cases. Kunit fixes could introduce quite bad consequences but those
are test code that affect only test run setups.

SJ Park (7):
mm/damon/core: initialize damos->last_applied
mm/damon/core-kunit: check region count before testing in split_at()
mm/damon/vaddr-kunit: check region count in three_regions test
mm/damon/core-kunit: handle region split failure in filter_out()
mm/damon/core-kunit: skip wrong dest walk in commit_dests_for()
mm/damon/core-kunit: skip wrong quota goal walk in
commit_quota_goals()
mm/damon/core-kunit: skip wrong region walk in commit_target_regions()

mm/damon/core.c | 1 +
mm/damon/tests/core-kunit.h | 28 ++++++++++++++++++++++++++--
mm/damon/tests/vaddr-kunit.h | 5 +++++
3 files changed, 32 insertions(+), 2 deletions(-)


base-commit: 1ce4cbd62f48552188b3f6fac8a14b709e97b7be
--
2.47.3

[SJ Park]

damon_test_split_at() test next region that is assumed to be created by
damon_split_region_at() invocation. But the split might fail. In this
case, the succeeding test may dereference invalid pointers returned by
damon_next_region().

The invalid pointer may not cause a really bad user impact, because of
the implementation detail. It would only read wrong contents in the
belonging damon_target struct. Depending on the future change of the
offset from the link header to the accessing field, this could also be
really dangerous, though. Still, the realistic user impact would be
limited. It would affect only test run setups.

Fix it by testing if the number of regions was also changed as expected
and exit early for the failure.

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/2026071414235...@kernel.org

Fixes: 17ccae8bb5c9 ("mm/damon: add kunit tests")
Cc: <sta...@vger.kernel.org> # 5.15.x

Signed-off-by: SJ Park <s...@kernel.org>
---

mm/damon/tests/core-kunit.h | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/mm/damon/tests/core-kunit.h b/mm/damon/tests/core-kunit.h
index eba643762132f..322a295ac2cec 100644
--- a/mm/damon/tests/core-kunit.h
+++ b/mm/damon/tests/core-kunit.h
@@ -155,6 +155,10 @@ static void damon_test_split_at(struct kunit *test)
r->age = 10;
damon_add_region(r, t);
damon_split_region_at(t, r, 25);
+ KUNIT_EXPECT_EQ(test, damon_nr_regions(t), 2);
+ if (damon_nr_regions(t) != 2)
+ goto out;
+
KUNIT_EXPECT_EQ(test, r->ar.start, 0ul);
KUNIT_EXPECT_EQ(test, r->ar.end, 25ul);

@@ -166,6 +170,7 @@ static void damon_test_split_at(struct kunit *test)
KUNIT_EXPECT_EQ(test, r->last_nr_accesses, r_new->last_nr_accesses);
KUNIT_EXPECT_EQ(test, r->age, r_new->age);

+out:
damon_free_target(t);
}

--
2.47.3

[SJ Park]

damos_test_commit_dests_for() traverse damos action destinations after
damos_commit_dests(). It assumes damos_commit_dests() made expected
numbers of destinations for source and destination structures. It might
not. Because the traversal is made based on destination struct length,
it could do out of bounds access for source value expectation.

The consequent user impact (out-of-bound access ) is quite bad. The
realistic user impact would be limited, though. It would affect only
test run setups.

Fix it by exiting early for the number of regions test failure.

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/202607131447...@kernel.org

Fixes: eec573b8dd65 ("mm/damon/tests/core-kunit: add damos_commit_dests() test")
Cc: <sta...@vger.kernel.org> # 6.19.x

Signed-off-by: SJ Park <s...@kernel.org>
---

mm/damon/tests/core-kunit.h | 2 ++
1 file changed, 2 insertions(+)

diff --git a/mm/damon/tests/core-kunit.h b/mm/damon/tests/core-kunit.h
index bd3bbd421392f..ca6ac12a15b24 100644
--- a/mm/damon/tests/core-kunit.h
+++ b/mm/damon/tests/core-kunit.h
@@ -1008,6 +1008,8 @@ static void damos_test_commit_dests_for(struct kunit *test,
skip = false;

KUNIT_EXPECT_EQ(test, dst.nr_dests, src_nr_dests);
+ if (dst.nr_dests != src_nr_dests)
+ goto out;
for (i = 0; i < dst.nr_dests; i++) {
KUNIT_EXPECT_EQ(test, dst.node_id_arr[i], src_node_id_arr[i]);
KUNIT_EXPECT_EQ(test, dst.weight_arr[i], src_weight_arr[i]);
--
2.47.3

[SJ Park]

damon_do_test_apply_three_regions() iterates regions after
damon_set_regions() call assuming the function would succeed at setting
the number of regions the same to the expected one. It might have
failed. In this case, __nth_region_of() in the iteration could return
NULL and NULL dereference can happen in the test.

The consequent user impact (NULL dereference) is quite bad. The
realistic user impact would be limited, though. It would affect only
test run setups.

Fix it by testing if the number of regions was also changed as expected

and exit early for the failure.

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/202607131447...@kernel.org

Fixes: 17ccae8bb5c9 ("mm/damon: add kunit tests")
Cc: <sta...@vger.kernel.org> # 5.15.x

Signed-off-by: SJ Park <s...@kernel.org>
---

mm/damon/tests/vaddr-kunit.h | 5 +++++

1 file changed, 5 insertions(+)

diff --git a/mm/damon/tests/vaddr-kunit.h b/mm/damon/tests/vaddr-kunit.h
index 61f844336ffb5..6a95441d193ae 100644
--- a/mm/damon/tests/vaddr-kunit.h
+++ b/mm/damon/tests/vaddr-kunit.h
@@ -158,12 +158,17 @@ static void damon_do_test_apply_three_regions(struct kunit *test,
kunit_skip(test, "second damon_set_regions() fail");
}

+ KUNIT_EXPECT_EQ(test, damon_nr_regions(t), nr_expected / 2);
+ if (damon_nr_regions(t) != nr_expected / 2)
+ goto out;
+
for (i = 0; i < nr_expected / 2; i++) {
r = __nth_region_of(t, i);
KUNIT_EXPECT_EQ(test, r->ar.start, expected[i * 2]);
KUNIT_EXPECT_EQ(test, r->ar.end, expected[i * 2 + 1]);
}

+out:
damon_destroy_target(t, NULL);
}

--
2.47.3

[SJ Park]

damon_test_commit_target_regions_for() traverses expected values array
after damon_commit_target_regions() call. It assumes
damon_commit_target_regions() made expected number of regions. It might
not. Because the traversal is made based on the region count, it could
do out of bounds access to the expectation value array.

The consequent user impact (out-of-bound access) is quite bad. The
realistic user impact would be limited, though. It would affect only
test run setups.

Fix it by testing if the number of regions was also changed as expected
and exit early for the failure.

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/202607131447...@kernel.org

Fixes: 603f67eb91e0 ("mm/damon/tests/core-kunit: add damon_commit_target_regions() test")
Cc: <sta...@vger.kernel.org> # 6.19.x

Signed-off-by: SJ Park <s...@kernel.org>
---

mm/damon/tests/core-kunit.h | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/mm/damon/tests/core-kunit.h b/mm/damon/tests/core-kunit.h
index c0fc903a6a259..805d15a64500d 100644
--- a/mm/damon/tests/core-kunit.h
+++ b/mm/damon/tests/core-kunit.h
@@ -1277,14 +1277,19 @@ static void damon_test_commit_target_regions_for(struct kunit *test,
kunit_skip(test, "src target setup fail");
}
damon_commit_target_regions(dst_target, src_target, 1);
+
+ KUNIT_EXPECT_EQ(test, damon_nr_regions(dst_target), nr_expect_regions);
+ if (damon_nr_regions(dst_target) != nr_expect_regions)
+ goto out;
+
i = 0;
damon_for_each_region(r, dst_target) {
KUNIT_EXPECT_EQ(test, r->ar.start, expect_start_end[i][0]);
KUNIT_EXPECT_EQ(test, r->ar.end, expect_start_end[i][1]);
i++;
}
- KUNIT_EXPECT_EQ(test, damon_nr_regions(dst_target), nr_expect_regions);
- KUNIT_EXPECT_EQ(test, i, nr_expect_regions);
+
+out:
damon_free_target(dst_target);
damon_free_target(src_target);
}
--
2.47.3

[SJ Park]

dasmon_test_filter_out() test checks if damos_filter_match() of an
address filter splits the region as expected under a given condition.
But, the test continued regardless of the split successes. As a result,
the later part of the test could dereference invalid pointers that
returned from damon_next_region(). Further, it could corrupt memory
from damon_destroy_region().

The consequent user impact (memory corruption) is quite bad. The
realistic user impact would be limited, though. It would affect only
test run setups.

Fix it by exiting early for the number of regions test failure.

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/2026071414235...@kernel.org

Fixes: 26713c890875 ("mm/damon/core-test: add a unit test for __damos_filter_out()")
Cc: <sta...@vger.kernel.org> # 6.6.x

Signed-off-by: SJ Park <s...@kernel.org>
---

mm/damon/tests/core-kunit.h | 3 +++
1 file changed, 3 insertions(+)

diff --git a/mm/damon/tests/core-kunit.h b/mm/damon/tests/core-kunit.h
index 322a295ac2cec..bd3bbd421392f 100644
--- a/mm/damon/tests/core-kunit.h
+++ b/mm/damon/tests/core-kunit.h
@@ -1365,6 +1365,8 @@ static void damos_test_filter_out(struct kunit *test)
KUNIT_EXPECT_EQ(test, r->ar.start, 1);
KUNIT_EXPECT_EQ(test, r->ar.end, 2);
KUNIT_EXPECT_EQ(test, damon_nr_regions(t), 2);
+ if (damon_nr_regions(t) != 2)
+ goto out;
r2 = damon_next_region(r);
KUNIT_EXPECT_EQ(test, r2->ar.start, 2);
KUNIT_EXPECT_EQ(test, r2->ar.end, 4);
@@ -1384,6 +1386,7 @@ static void damos_test_filter_out(struct kunit *test)
KUNIT_EXPECT_EQ(test, r2->ar.end, 8);
damon_destroy_region(r2, t);

+out:
damon_free_target(t);
damos_free_filter(f);
}
--
2.47.3

[SJ Park]

damos_test_commit_quota_goals_for() traverses damos quota goals after
damos_commit_quota_goals() call. It assumes damos_commit_quota_goals()
made expected numbers of goals. It might not. Because the traversal is
made based on destination struct length, it could do out of bounds
access for source expectation value array.

The consequent user impact (out-of-bound access ) is quite bad. The
realistic user impact would be limited though. It would affect only
test run setups.

Fix it by testing if the number of goals was also changed as expected
and exit early for the failure.

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/202607131447...@kernel.org

Fixes: d9adfb8a28e7 ("mm/damon/tests/core-kunit: add damos_commit_quota_goals() test")
Cc: <sta...@vger.kernel.org> # 6.19.x

Signed-off-by: SJ Park <s...@kernel.org>
---

mm/damon/tests/core-kunit.h | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/mm/damon/tests/core-kunit.h b/mm/damon/tests/core-kunit.h
index ca6ac12a15b24..c0fc903a6a259 100644
--- a/mm/damon/tests/core-kunit.h
+++ b/mm/damon/tests/core-kunit.h
@@ -839,6 +839,7 @@ static void damos_test_commit_quota_goals_for(struct kunit *test,
struct damos_quota_goal *goal, *next;
bool skip = true;
int i;
+ int nr_dst = 0, nr_src = 0;

INIT_LIST_HEAD(&dst.goals);
INIT_LIST_HEAD(&src.goals);
@@ -861,6 +862,14 @@ static void damos_test_commit_quota_goals_for(struct kunit *test,

damos_commit_quota_goals(&dst, &src);

+ damos_for_each_quota_goal(goal, &dst)
+ nr_dst++;
+ damos_for_each_quota_goal(goal, &src)
+ nr_src++;
+ KUNIT_EXPECT_EQ(test, nr_dst, nr_src);
+ if (nr_dst != nr_src)

+ goto out;
+
i = 0;

damos_for_each_quota_goal(goal, (&dst)) {
KUNIT_EXPECT_EQ(test, goal->metric, src_goals[i].metric);
--
2.47.3

[SJ Park]

On Thu, 16 Jul 2026 17:30:14 -0700 SJ Park <s...@kernel.org> wrote:

> Fix a few Sashiko-found unurgent bugs. Patch 1 fixes use of
> uninitialized damos->last_applied field. Patches 2-7 fix DAMON kunit
> tests that do invalid memory access under test failures.

This was meant to be RFC, but I forgot adding the tag. Andrew, please don't
merge this as is. Sorry for confusing people.


Thanks,
SJ

[...]

[SJ Park]

Fix a few Sashiko-found unurgent bugs. Patch 1 fixes use of
uninitialized damos->last_applied field. Patches 2-7 fix DAMON kunit
tests that do invalid memory access under test failures.

The bugs are better to be fixed and eventually merged into stable@
kernel. That said, the fixes are arguably not urgent. Patch 1 only
introduces negligible DAMOS efficiency degradation in occasional
cases. Kunit fixes could introduce quite bad consequences but those

are test code that affect only test run setups.

Changes from RFC
- RFC: https://lore.kernel.org/2026071700302...@kernel.org
- Add missed region split failure check in filter_out() test.
- Rebase to latest mm-new.

SJ Park (7):
mm/damon/core: initialize damos->last_applied
mm/damon/core-kunit: check region count before testing in split_at()
mm/damon/vaddr-kunit: check region count in three_regions test
mm/damon/core-kunit: handle region split failure in filter_out()
mm/damon/core-kunit: skip wrong dest walk in commit_dests_for()
mm/damon/core-kunit: skip wrong quota goal walk in
commit_quota_goals()
mm/damon/core-kunit: skip wrong region walk in commit_target_regions()

mm/damon/core.c | 1 +

mm/damon/tests/core-kunit.h | 30 ++++++++++++++++++++++++++++--
mm/damon/tests/vaddr-kunit.h | 5 +++++
3 files changed, 34 insertions(+), 2 deletions(-)


base-commit: 0ad94b65c75dc6c6c3fa742f0a6213ed578c771a
--
2.47.3

[SJ Park]

Multiple DAMON regions could exist across a folio. If they fulfill the
condition to apply a DAMOS scheme, the scheme could be applied multiple
times to the folio. To avoid this, each DAMOS scheme stores the folio
that the scheme was applied to last time in the damos->last_applied
field and skips repeatedly applying the same scheme to the same folio.

The field is being used without initialization, though. Hence, the
mechanism could wrongly skip applying a scheme to a folio at the very
first time of DAMOS run.

The user impact is trivial. DAMON might unexpectedly skip applying
DAMOS action for one folio for the first time per scheme. In the
DAMON's best-effort world, this is never a real problem. No critical
consequences such as kernel panic or memory corruption happen.

It is a clear bug, though, and the fix is straightforward. Fix the
issue by initializing the field in DAMOS scheme creation function,
damon_new_scheme().

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/2026071405543...@kernel.org

Fixes: 94ba17adaba0 ("mm/damon: avoid applying DAMOS action to same entity multiple times")
Cc: <sta...@vger.kernel.org> # 6.15.x

Signed-off-by: SJ Park <s...@kernel.org>
---

[SJ Park]

damon_test_split_at() test next region that is assumed to be created by
damon_split_region_at() invocation. But the split might fail. In this
case, the succeeding test may dereference invalid pointers returned by
damon_next_region().

The invalid pointer may not cause a really bad user impact, because of
the implementation detail. It would only read wrong contents in the
belonging damon_target struct. Depending on the future change of the
offset from the link header to the accessing field, this could also be

really dangerous, though. Still, the realistic user impact would be
limited. It would affect only test run setups.

Fix it by testing if the number of regions was also changed as expected

and exit early for the failure.

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/2026071414235...@kernel.org

Fixes: 17ccae8bb5c9 ("mm/damon: add kunit tests")
Cc: <sta...@vger.kernel.org> # 5.15.x

Signed-off-by: SJ Park <s...@kernel.org>
---

mm/damon/tests/core-kunit.h | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/mm/damon/tests/core-kunit.h b/mm/damon/tests/core-kunit.h
index eba643762132f..322a295ac2cec 100644
--- a/mm/damon/tests/core-kunit.h
+++ b/mm/damon/tests/core-kunit.h

@@ -155,6 +155,10 @@ static void damon_test_split_at(struct kunit *test)
r->age = 10;
damon_add_region(r, t);
damon_split_region_at(t, r, 25);

+ KUNIT_EXPECT_EQ(test, damon_nr_regions(t), 2);

+ if (damon_nr_regions(t) != 2)
+ goto out;

[SJ Park]

damon_do_test_apply_three_regions() iterates regions after
damon_set_regions() call assuming the function would succeed at setting
the number of regions the same to the expected one. It might have
failed. In this case, __nth_region_of() in the iteration could return
NULL and NULL dereference can happen in the test.

The consequent user impact (NULL dereference) is quite bad. The

realistic user impact would be limited, though. It would affect only
test run setups.

Fix it by testing if the number of regions was also changed as expected
and exit early for the failure.

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/202607131447...@kernel.org

Fixes: 17ccae8bb5c9 ("mm/damon: add kunit tests")
Cc: <sta...@vger.kernel.org> # 5.15.x
Signed-off-by: SJ Park <s...@kernel.org>
---

mm/damon/tests/vaddr-kunit.h | 5 +++++

1 file changed, 5 insertions(+)

diff --git a/mm/damon/tests/vaddr-kunit.h b/mm/damon/tests/vaddr-kunit.h
index 61f844336ffb5..6a95441d193ae 100644
--- a/mm/damon/tests/vaddr-kunit.h
+++ b/mm/damon/tests/vaddr-kunit.h
@@ -158,12 +158,17 @@ static void damon_do_test_apply_three_regions(struct kunit *test,
kunit_skip(test, "second damon_set_regions() fail");
}

+ KUNIT_EXPECT_EQ(test, damon_nr_regions(t), nr_expected / 2);
+ if (damon_nr_regions(t) != nr_expected / 2)
+ goto out;
+

[SJ Park]

damos_test_commit_quota_goals_for() traverses damos quota goals after
damos_commit_quota_goals() call. It assumes damos_commit_quota_goals()
made expected numbers of goals. It might not. Because the traversal is
made based on destination struct length, it could do out of bounds
access for source expectation value array.

The consequent user impact (out-of-bound access ) is quite bad. The
realistic user impact would be limited though. It would affect only
test run setups.

Fix it by testing if the number of goals was also changed as expected

and exit early for the failure.

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/202607131447...@kernel.org

Fixes: d9adfb8a28e7 ("mm/damon/tests/core-kunit: add damos_commit_quota_goals() test")
Cc: <sta...@vger.kernel.org> # 6.19.x

Signed-off-by: SJ Park <s...@kernel.org>
---

mm/damon/tests/core-kunit.h | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/mm/damon/tests/core-kunit.h b/mm/damon/tests/core-kunit.h
index 9b8c20a50ad53..fbf986aee2dea 100644
--- a/mm/damon/tests/core-kunit.h
+++ b/mm/damon/tests/core-kunit.h

[SJ Park]

damos_test_commit_dests_for() traverse damos action destinations after
damos_commit_dests(). It assumes damos_commit_dests() made expected

numbers of destinations for source and destination structures. It might

not. Because the traversal is made based on destination struct length,

it could do out of bounds access for source value expectation.

The consequent user impact (out-of-bound access ) is quite bad. The

realistic user impact would be limited, though. It would affect only
test run setups.

Fix it by exiting early for the number of regions test failure.

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/202607131447...@kernel.org

Fixes: eec573b8dd65 ("mm/damon/tests/core-kunit: add damos_commit_dests() test")

Cc: <sta...@vger.kernel.org> # 6.19.x
Signed-off-by: SJ Park <s...@kernel.org>
---

mm/damon/tests/core-kunit.h | 2 ++
1 file changed, 2 insertions(+)

diff --git a/mm/damon/tests/core-kunit.h b/mm/damon/tests/core-kunit.h
index eddf3a0484583..9b8c20a50ad53 100644
--- a/mm/damon/tests/core-kunit.h
+++ b/mm/damon/tests/core-kunit.h

[SJ Park]

dasmon_test_filter_out() test checks if damos_filter_match() of an
address filter splits the region as expected under a given condition.
But, the test continued regardless of the split successes. As a result,
the later part of the test could dereference invalid pointers that
returned from damon_next_region(). Further, it could corrupt memory
from damon_destroy_region().

The consequent user impact (memory corruption) is quite bad. The
realistic user impact would be limited, though. It would affect only
test run setups.

Fix it by exiting early for the number of regions test failure.

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/2026071414235...@kernel.org

Fixes: 26713c890875 ("mm/damon/core-test: add a unit test for __damos_filter_out()")
Cc: <sta...@vger.kernel.org> # 6.6.x

Signed-off-by: SJ Park <s...@kernel.org>
---

mm/damon/tests/core-kunit.h | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/mm/damon/tests/core-kunit.h b/mm/damon/tests/core-kunit.h
index 322a295ac2cec..eddf3a0484583 100644
--- a/mm/damon/tests/core-kunit.h
+++ b/mm/damon/tests/core-kunit.h

@@ -1365,6 +1365,8 @@ static void damos_test_filter_out(struct kunit *test)
KUNIT_EXPECT_EQ(test, r->ar.start, 1);
KUNIT_EXPECT_EQ(test, r->ar.end, 2);
KUNIT_EXPECT_EQ(test, damon_nr_regions(t), 2);
+ if (damon_nr_regions(t) != 2)
+ goto out;
r2 = damon_next_region(r);
KUNIT_EXPECT_EQ(test, r2->ar.start, 2);
KUNIT_EXPECT_EQ(test, r2->ar.end, 4);

@@ -1379,11 +1381,14 @@ static void damos_test_filter_out(struct kunit *test)
KUNIT_EXPECT_EQ(test, r->ar.start, 2);
KUNIT_EXPECT_EQ(test, r->ar.end, 6);

KUNIT_EXPECT_EQ(test, damon_nr_regions(t), 2);
+ if (damon_nr_regions(t) != 2)
+ goto out;
r2 = damon_next_region(r);

KUNIT_EXPECT_EQ(test, r2->ar.start, 6);

[SJ Park]

damon_test_commit_target_regions_for() traverses expected values array
after damon_commit_target_regions() call. It assumes
damon_commit_target_regions() made expected number of regions. It might
not. Because the traversal is made based on the region count, it could
do out of bounds access to the expectation value array.

The consequent user impact (out-of-bound access) is quite bad. The
realistic user impact would be limited, though. It would affect only
test run setups.

Fix it by testing if the number of regions was also changed as expected
and exit early for the failure.

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/202607131447...@kernel.org

Fixes: 603f67eb91e0 ("mm/damon/tests/core-kunit: add damon_commit_target_regions() test")
Cc: <sta...@vger.kernel.org> # 6.19.x

Signed-off-by: SJ Park <s...@kernel.org>
---

mm/damon/tests/core-kunit.h | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/mm/damon/tests/core-kunit.h b/mm/damon/tests/core-kunit.h
index fbf986aee2dea..4a536d41cdb2d 100644
--- a/mm/damon/tests/core-kunit.h
+++ b/mm/damon/tests/core-kunit.h

@@ -1277,14 +1277,19 @@ static void damon_test_commit_target_regions_for(struct kunit *test,
kunit_skip(test, "src target setup fail");
}
damon_commit_target_regions(dst_target, src_target, 1);
+
+ KUNIT_EXPECT_EQ(test, damon_nr_regions(dst_target), nr_expect_regions);
+ if (damon_nr_regions(dst_target) != nr_expect_regions)

+ goto out;
+
i = 0;

[SJ Park]

damon_test_split_at() test next region that is assumed to be created by
damon_split_region_at() invocation. But the split might fail. In this
case, the succeeding test may dereference invalid pointers returned by
damon_next_region().

The invalid pointer may not cause a really bad user impact, because of
the implementation detail. It would only read wrong contents in the
belonging damon_target struct. Depending on the future change of the
offset from the link header to the accessing field, this could also be

really dangerous, though. Still, the realistic user impact would be
limited. It would affect only test run setups.

Fix it by testing if the number of regions was also changed as expected
and exit early for the failure.

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/2026071414235...@kernel.org

Fixes: 17ccae8bb5c9 ("mm/damon: add kunit tests")
Cc: <sta...@vger.kernel.org> # 5.15.x

Signed-off-by: SJ Park <s...@kernel.org>
---

mm/damon/tests/core-kunit.h | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/mm/damon/tests/core-kunit.h b/mm/damon/tests/core-kunit.h
index eba643762132f..322a295ac2cec 100644
--- a/mm/damon/tests/core-kunit.h
+++ b/mm/damon/tests/core-kunit.h

@@ -155,6 +155,10 @@ static void damon_test_split_at(struct kunit *test)
r->age = 10;
damon_add_region(r, t);
damon_split_region_at(t, r, 25);

+ KUNIT_EXPECT_EQ(test, damon_nr_regions(t), 2);

+ if (damon_nr_regions(t) != 2)
+ goto out;

[SJ Park]

Fix a few Sashiko-found unurgent bugs. Patch 1 fixes use of
uninitialized damos->last_applied field. Patches 2-7 fix DAMON kunit
tests that do invalid memory access under test failures.

The bugs are better to be fixed and eventually merged into stable@
kernel. That said, the fixes are arguably not urgent. Patch 1 only
introduces negligible DAMOS efficiency degradation in occasional
cases. Kunit fixes could introduce quite bad consequences but those

are test code that affect only test run setups.

Changes from RFC v1.1
- RFC v1.1: https://lore.kernel.org/202607171434...@kernel.org
- Drop RFC.

Changes from RFC
- RFC: https://lore.kernel.org/2026071700302...@kernel.org

(Was not having RFC tag on the subject by a mistake)

- Add missed region split failure check in filter_out() test.
- Rebase to latest mm-new.

SJ Park (7):
mm/damon/core: initialize damos->last_applied
mm/damon/core-kunit: check region count before testing in split_at()
mm/damon/vaddr-kunit: check region count in three_regions test
mm/damon/core-kunit: handle region split failure in filter_out()
mm/damon/core-kunit: skip wrong dest walk in commit_dests_for()
mm/damon/core-kunit: skip wrong quota goal walk in
commit_quota_goals()
mm/damon/core-kunit: skip wrong region walk in commit_target_regions()

mm/damon/core.c | 1 +
mm/damon/tests/core-kunit.h | 30 ++++++++++++++++++++++++++++--
mm/damon/tests/vaddr-kunit.h | 5 +++++
3 files changed, 34 insertions(+), 2 deletions(-)

base-commit: 6bb81496f18939ccbc5f16840d5b2cf1af6c995e
--
2.47.3

[SJ Park]

damon_do_test_apply_three_regions() iterates regions after
damon_set_regions() call assuming the function would succeed at setting
the number of regions the same to the expected one. It might have
failed. In this case, __nth_region_of() in the iteration could return
NULL and NULL dereference can happen in the test.

The consequent user impact (NULL dereference) is quite bad. The

realistic user impact would be limited, though. It would affect only
test run setups.

Fix it by testing if the number of regions was also changed as expected
and exit early for the failure.

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/202607131447...@kernel.org

Fixes: 17ccae8bb5c9 ("mm/damon: add kunit tests")
Cc: <sta...@vger.kernel.org> # 5.15.x
Signed-off-by: SJ Park <s...@kernel.org>
---

mm/damon/tests/vaddr-kunit.h | 5 +++++

1 file changed, 5 insertions(+)

diff --git a/mm/damon/tests/vaddr-kunit.h b/mm/damon/tests/vaddr-kunit.h
index 61f844336ffb5..6a95441d193ae 100644
--- a/mm/damon/tests/vaddr-kunit.h
+++ b/mm/damon/tests/vaddr-kunit.h
@@ -158,12 +158,17 @@ static void damon_do_test_apply_three_regions(struct kunit *test,
kunit_skip(test, "second damon_set_regions() fail");
}

+ KUNIT_EXPECT_EQ(test, damon_nr_regions(t), nr_expected / 2);
+ if (damon_nr_regions(t) != nr_expected / 2)
+ goto out;
+

[SJ Park]

Multiple DAMON regions could exist across a folio. If they fulfill the
condition to apply a DAMOS scheme, the scheme could be applied multiple
times to the folio. To avoid this, each DAMOS scheme stores the folio
that the scheme was applied to last time in the damos->last_applied
field and skips repeatedly applying the same scheme to the same folio.

The field is being used without initialization, though. Hence, the
mechanism could wrongly skip applying a scheme to a folio at the very
first time of DAMOS run.

The user impact is trivial. DAMON might unexpectedly skip applying
DAMOS action for one folio for the first time per scheme. In the
DAMON's best-effort world, this is never a real problem. No critical
consequences such as kernel panic or memory corruption happen.

It is a clear bug, though, and the fix is straightforward. Fix the
issue by initializing the field in DAMOS scheme creation function,
damon_new_scheme().

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/2026071405543...@kernel.org

Fixes: 94ba17adaba0 ("mm/damon: avoid applying DAMOS action to same entity multiple times")
Cc: <sta...@vger.kernel.org> # 6.15.x

Signed-off-by: SJ Park <s...@kernel.org>
---

[SJ Park]

damos_test_commit_dests_for() traverse damos action destinations after
damos_commit_dests(). It assumes damos_commit_dests() made expected

numbers of destinations for source and destination structures. It might
not. Because the traversal is made based on destination struct length,
it could do out of bounds access for source value expectation.

The consequent user impact (out-of-bound access ) is quite bad. The
realistic user impact would be limited, though. It would affect only
test run setups.

Fix it by exiting early for the number of regions test failure.

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/202607131447...@kernel.org

Fixes: eec573b8dd65 ("mm/damon/tests/core-kunit: add damos_commit_dests() test")
Cc: <sta...@vger.kernel.org> # 6.19.x

Signed-off-by: SJ Park <s...@kernel.org>
---

mm/damon/tests/core-kunit.h | 2 ++
1 file changed, 2 insertions(+)

diff --git a/mm/damon/tests/core-kunit.h b/mm/damon/tests/core-kunit.h
index eddf3a0484583..9b8c20a50ad53 100644
--- a/mm/damon/tests/core-kunit.h
+++ b/mm/damon/tests/core-kunit.h

[SJ Park]

dasmon_test_filter_out() test checks if damos_filter_match() of an
address filter splits the region as expected under a given condition.
But, the test continued regardless of the split successes. As a result,
the later part of the test could dereference invalid pointers that
returned from damon_next_region(). Further, it could corrupt memory
from damon_destroy_region().

The consequent user impact (memory corruption) is quite bad. The
realistic user impact would be limited, though. It would affect only
test run setups.

Fix it by exiting early for the number of regions test failure.

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/2026071414235...@kernel.org

Fixes: 26713c890875 ("mm/damon/core-test: add a unit test for __damos_filter_out()")
Cc: <sta...@vger.kernel.org> # 6.6.x

Signed-off-by: SJ Park <s...@kernel.org>
---

mm/damon/tests/core-kunit.h | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/mm/damon/tests/core-kunit.h b/mm/damon/tests/core-kunit.h
index 322a295ac2cec..eddf3a0484583 100644
--- a/mm/damon/tests/core-kunit.h
+++ b/mm/damon/tests/core-kunit.h

[SJ Park]

damos_test_commit_quota_goals_for() traverses damos quota goals after
damos_commit_quota_goals() call. It assumes damos_commit_quota_goals()

made expected numbers of goals. It might not. Because the traversal is

made based on destination struct length, it could do out of bounds

access for source expectation value array.

The consequent user impact (out-of-bound access ) is quite bad. The
realistic user impact would be limited though. It would affect only
test run setups.

Fix it by testing if the number of goals was also changed as expected
and exit early for the failure.

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/202607131447...@kernel.org

Fixes: d9adfb8a28e7 ("mm/damon/tests/core-kunit: add damos_commit_quota_goals() test")
Cc: <sta...@vger.kernel.org> # 6.19.x

Signed-off-by: SJ Park <s...@kernel.org>
---

mm/damon/tests/core-kunit.h | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/mm/damon/tests/core-kunit.h b/mm/damon/tests/core-kunit.h
index 9b8c20a50ad53..fbf986aee2dea 100644
--- a/mm/damon/tests/core-kunit.h
+++ b/mm/damon/tests/core-kunit.h

@@ -839,6 +839,7 @@ static void damos_test_commit_quota_goals_for(struct kunit *test,
struct damos_quota_goal *goal, *next;
bool skip = true;
int i;
+ int nr_dst = 0, nr_src = 0;

INIT_LIST_HEAD(&dst.goals);
INIT_LIST_HEAD(&src.goals);
@@ -861,6 +862,14 @@ static void damos_test_commit_quota_goals_for(struct kunit *test,

damos_commit_quota_goals(&dst, &src);

+ damos_for_each_quota_goal(goal, &dst)
+ nr_dst++;
+ damos_for_each_quota_goal(goal, &src)
+ nr_src++;
+ KUNIT_EXPECT_EQ(test, nr_dst, nr_src);
+ if (nr_dst != nr_src)

+ goto out;
+
i = 0;

[SJ Park]

damon_test_commit_target_regions_for() traverses expected values array
after damon_commit_target_regions() call. It assumes

damon_commit_target_regions() made expected number of regions. It might
not. Because the traversal is made based on the region count, it could
do out of bounds access to the expectation value array.

The consequent user impact (out-of-bound access) is quite bad. The
realistic user impact would be limited, though. It would affect only
test run setups.

Fix it by testing if the number of regions was also changed as expected

and exit early for the failure.

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/202607131447...@kernel.org

Fixes: 603f67eb91e0 ("mm/damon/tests/core-kunit: add damon_commit_target_regions() test")

Cc: <sta...@vger.kernel.org> # 6.19.x
Signed-off-by: SJ Park <s...@kernel.org>
---

mm/damon/tests/core-kunit.h | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/mm/damon/tests/core-kunit.h b/mm/damon/tests/core-kunit.h
index fbf986aee2dea..4a536d41cdb2d 100644
--- a/mm/damon/tests/core-kunit.h
+++ b/mm/damon/tests/core-kunit.h

@@ -1277,14 +1277,19 @@ static void damon_test_commit_target_regions_for(struct kunit *test,
kunit_skip(test, "src target setup fail");
}
damon_commit_target_regions(dst_target, src_target, 1);
+
+ KUNIT_EXPECT_EQ(test, damon_nr_regions(dst_target), nr_expect_regions);
+ if (damon_nr_regions(dst_target) != nr_expect_regions)

+ goto out;
+
i = 0;

[SJ Park]

On Fri, 17 Jul 2026 17:14:34 -0700 SJ Park <s...@kernel.org> wrote:

> Fix a few Sashiko-found unurgent bugs. Patch 1 fixes use of
> uninitialized damos->last_applied field. Patches 2-7 fix DAMON kunit
> tests that do invalid memory access under test failures.

Sashiko found no blocker for this series. Sashiko sent findings to damon@
mailing list [1], and I replied to all the comments. Please read those for
details.

[1] https://lore.kernel.org/damon/


Thanks,
SJ

[...]