wireguard-linux/mm/damon/tests, branch stable

treewide: refresh kmalloc_obj() conversions

2026-09-05T04:37:00Z

This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook

mm/damon/core-kunit: skip wrong region walk in commit_target_regions()

2026-08-07T01:57:17Z

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. Link: https://lore.kernel.org/20260718001442.87129-8-sj@kernel.org Link: https://lore.kernel.org/20260713144757.39740-1-sj@kernel.org [1] Fixes: 603f67eb91e0 ("mm/damon/tests/core-kunit: add damon_commit_target_regions() test") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 6.19.x Signed-off-by: Andrew Morton

mm/damon/core-kunit: skip wrong quota goal walk in commit_quota_goals()

2026-08-07T01:57:17Z

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. Link: https://lore.kernel.org/20260718001442.87129-7-sj@kernel.org Link: https://lore.kernel.org/20260713144757.39740-1-sj@kernel.org [1] Fixes: d9adfb8a28e7 ("mm/damon/tests/core-kunit: add damos_commit_quota_goals() test") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 6.19.x Signed-off-by: Andrew Morton

mm/damon/core-kunit: skip wrong dest walk in commit_dests_for()

2026-08-07T01:57:17Z

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. Link: https://lore.kernel.org/20260718001442.87129-6-sj@kernel.org Link: https://lore.kernel.org/20260713144757.39740-1-sj@kernel.org [1] Fixes: eec573b8dd65 ("mm/damon/tests/core-kunit: add damos_commit_dests() test") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 6.19.x Signed-off-by: Andrew Morton

mm/damon/core-kunit: handle region split failure in filter_out()

2026-08-07T01:57:17Z

damos_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. Link: https://lore.kernel.org/20260718001442.87129-5-sj@kernel.org Link: https://lore.kernel.org/20260714142352.100478-1-sj@kernel.org [1] Fixes: 26713c890875 ("mm/damon/core-test: add a unit test for __damos_filter_out()") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 6.6.x Signed-off-by: Andrew Morton

mm/damon/vaddr-kunit: check region count in three_regions test

2026-08-07T01:57:16Z

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. Link: https://lore.kernel.org/20260718001442.87129-4-sj@kernel.org Link: https://lore.kernel.org/20260713144757.39740-1-sj@kernel.org [1] Fixes: 17ccae8bb5c9 ("mm/damon: add kunit tests") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 5.15.x Signed-off-by: Andrew Morton

mm/damon/core-kunit: check region count before testing in split_at()

2026-08-07T01:57:16Z

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. Link: https://lore.kernel.org/20260718001442.87129-3-sj@kernel.org Link: https://lore.kernel.org/20260714142352.100478-1-sj@kernel.org [1] Fixes: 17ccae8bb5c9 ("mm/damon: add kunit tests") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 5.15.x Signed-off-by: Andrew Morton

mm/damon/tests/core-kunit: catch test failure in test_merge_regions_of()

2026-08-07T01:57:08Z

KUNIT_EXPECT_EQ() does not abort the execution of test code when the expectation is not met. But damon_test_merge_regions_of() code after its initial KUNIT_EXPECT_EQ() call assumes the expectation is met. It does a per-region test with a hard-coded number of regions that is correct only if the expectation was met. As a result, __nth_region_of() could return NULL, and the test code can dereference NULL pointers. Fix the issue by catching the expectation failure and skip the per-region tests. The user impact on realistic setups should be negligible, as it is a unit test. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-3-sj@kernel.org Link: https://lore.kernel.org/20260710144937.26981-1-sj@kernel.org [1] Fixes: 17ccae8bb5c9 ("mm/damon: add kunit tests") Signed-off-by: SJ Park Cc: # 5.15.x Signed-off-by: Andrew Morton

mm/damon/core: skip aging from repeated aggressive merging

2026-08-07T01:56:57Z

The number of DAMON regions could temporarily exceed the user-defined maximum number of regions limit for corner cases. For example, users could lower the limit via runtime parameters update. For such a case, kdamond_merge_regions() repeats merging regions in the case doubling the merge threshold. The repeated merge operation could update the age of regions multiple times. This corrupts the monitoring results. Fix the issue by asking the merge operation to skip aging for the corner case. The user impact is degradation of the monitoring quality. The impact should be mild, since the degradation is only temporal, and it is not common to happen in realistic setups. The issue was discovered [1,2] by Sashiko. Link: https://lore.kernel.org/20260712165432.87609-1-sj@kernel.org Link: https://lore.kernel.org/20260621203548.10718-1-sj@kernel.org [1] Link: https://lore.kernel.org/20260709145425.96247-1-sj@kernel.org [2] Fixes: 310d6c15e910 ("mm/damon/core: merge regions aggressively when max_nr_regions is unmet") Signed-off-by: SJ Park Cc: # 6.10 Signed-off-by: Andrew Morton

mm/damon/tests/core-kunit: test damon_nr_accesses_mvsum()

2026-08-07T01:56:55Z

damon_nr_accesses_mvsum() wraps damon_mvsum() with the monitoring intervals of the context to compute the pseudo moving sum of a region's access frequency, with a special case for when the whole aggregation window remains. damon_mvsum() itself is already covered by damon_test_mvsum(), but the wrapper is not. Add a table-driven KUnit test that exercises the full-window-remaining boundary (with both reset and not-yet-reset nr_accesses), partially elapsed windows, and the no-window-remaining case. Link: https://lore.kernel.org/20260713094648.897239-1-husong@kylinos.cn Signed-off-by: Song Hu Reviewed-by: SJ Park Signed-off-by: Andrew Morton