kernel/git/stable/linux.git/mm/damon, branch linux-rolling-stable

mm/damon/vaddr: drop last same folio access check optimization

2026-09-11T09:51:25+00:00

commit 831846078caa14b7d00b2ccca8b8fe522afe3204 upstream. The optimization can race when multiple kdamonds are running. Meanwhile, the impact of the optimization is quite doubtful. Just remove it. The user impact of the issue should be quite trivial. After all, the race can happen only when the user intentionally setup DAMON in the way. Even if it happens, it would be rare and only degrade the best-effort monitoring results. No critical consequences like kernel panic or memory corruption happen. The race possibility was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-4-sj@kernel.org Link: https://lore.kernel.org/20260621204050.10993-1-sj@kernel.org [1] Fixes: 3f49584b262c ("mm/damon: implement primitives for the virtual memory address spaces") Signed-off-by: SJ Park Cc: # 5.15.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman

mm/damon/paddr: drop last same folio access check reuse optimization

2026-09-11T09:51:25+00:00

commit f23f0aa62b2f32c2b12f95959fc4603ef81678b2 upstream. It can race when multiple kdamonds are being used. The problem from the race is doubtful, but the gain from the optimization is also doubtful. Simply drop the optimization in favor of code simplicity. The user impact is doubtfully trivial. After all, this kind of interference can happen only by intentional user setup. Even if it happens, it will be rare, and the consequence is degradation of the best-effort monitoring results. No critical consequences like kernel panic or memory corruption happen. The race was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-5-sj@kernel.org Link: https://lore.kernel.org/20260621204050.10993-1-sj@kernel.org [1] Fixes: a28397beb55b ("mm/damon: implement primitives for physical address space monitoring") Signed-off-by: SJ Park Cc: # 5.16.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman

mm/damon/ops-common: use nr_accesses moving sum for quota score

2026-09-11T09:51:25+00:00

commit 6c25083f7ae7e2660d766169e5b4d3e96010503f upstream. Since commit 42f994b71404 ("mm/damon/core: implement scheme-specific apply interval"), DAMOS scheme can be applied at any time. At that time, nr_accesses may not be fully aggregated. But the quota prioritization score is calculated using the not fully aggregated count. As a result, the performance of DAMOS could be degraded. Fix by using damon_nr_accesses_mvsum() instead. The user impact of the issue is suboptimum DAMOS performance under certain setups. Nonetheless, the bug was there from the beginning of the setup availability. In other words, the suboptimum performance is the baseline of the setup and hence it didn't cause regression. Also the extent of the suboptimality was not big enough to be found from users and testers. Still, this is a clear bug that is better to be fixed, and can be easily fixed. Link: https://lore.kernel.org/20260719161136.90191-1-sj@kernel.org Fixes: 42f994b71404 ("mm/damon/core: implement scheme-specific apply interval") Signed-off-by: SJ Park Cc: # 6.7.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman

mm/damon/core: avoid infinite kdamond_merge_regions() internal loop

2026-09-11T09:51:25+00:00

commit 123e4619ab6c8ab1c4cb1d7a58311a2af13929cd upstream. Patch series "mm/damon: unurgent fixes for infinite loop, NULL de-ref and races", v1.1. Sashiko found a few issues in DAMON that could cause infinite loop, NULL dereference and monitoring results degradation. The first two sounds scary but the infinite loop happens only under unreasonable user setup. The NULL dereference is only in a unit test. Monitoring results degradation is trivial since it is only best-effort, and those happens from only unlikely races. Still those are bugs that better to fix if possible. Fix those. This patch (of 6): Due to online parameter update like events, the number of DAMON regions could be higher than the user-set upper limit. kdamond_merge_regions() repeats merge regions until the number meets the limit, while doubling the merge threshold up to the theoretical maximum threshold. It is tried only up to the theoretical maximum threshold because even the aggressive merging can fail from reducing the number of regions under the user-defined upper limit. For example, there could be many user-defined non-contiguous regions that cannot be merged. The threshold based loop break condition is evaluated by comparing the threshold for the next merging try against the theoretical maximum threshold. If max_thres is larger than UINT_MAX / 2, doubling the threshold could make it overflow, and bypass the loop break condition. In the case, if the number of regions cannot be reduced under the upper limit like explained above, the loop will run infinitely. Prevent the case by doing the break condition check before doubling the threshold. Also, prevent the threshold exceeding the maximum threshold, as it could overflow and apply the wrong merge threshold. This issue is unlikely to occur in real world, since having the max_thres higher than UINT_MAX / 2 require unrealistically large aggregation intervals compared to the sampling interval. Also, it requires an unrealistically large number of uncontiguous regions setup. Nonetheless, the consequence is bad and the fix is simple. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260715031002.108504-1-sj@kernel.org Link: https://lore.kernel.org/20260715031002.108504-2-sj@kernel.org Link: https://lore.kernel.org/20260709145425.96247-1-sj@kernel.org [1] Fixes: 310d6c15e910 ("mm/damon/core: merge regions aggressively when max_nr_regions is unmet") Signed-off-by: SJ Park Cc: # 6.10.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman

mm/damon/core: initialize damos->last_applied

2026-09-11T09:50:50+00:00

commit af5f76aeb9c9aa9c77d5e1d94e0ee4618c805239 upstream. Patch series "mm/damon: fix uninitialized DAMOS field and kunit exec expectation bugs". 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. This patch (of 7): 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. Link: https://lore.kernel.org/20260718001442.87129-1-sj@kernel.org Link: https://lore.kernel.org/20260718001442.87129-2-sj@kernel.org Link: https://lore.kernel.org/20260714055436.120034-1-sj@kernel.org [1] Fixes: 94ba17adaba0 ("mm/damon: avoid applying DAMOS action to same entity multiple times") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 6.15.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

mm/damon/core: handle region split failure in apply_min_nr_regions()

2026-09-11T09:50:50+00:00

commit c608748607620f331196ed0ba9fe4017892c1457 upstream. damon_apply_min_nr_regions() repeatedly split each region until its size becomes small enough to meet the user-defined low limit of the number of regions. The loop assumes the split operation (damon_split_region_at()) will always succeed and create the new region. But the operation could silently fail for memory allocation failures, for example. If such failure happens and the region was the last region, the linked list-based next region fetching returns invalid pointer. As a result, invalid memory dereference and corruption could happen. Even if the corner case is handled, it imposes stress to the allocator by trying split regions for other targets. Fix the issue by breaking all the loops for any region split failure. This means there could be a min_nr_regions violation. It will only rarely happen since the allocation is arguably too small to fail. Even if it happens, it is only temporal. damon_apply_min_nr_regions() will be called again after the aggregation interval. The user impact of the issue should be minor, since the allocation is arguably too small to fail. But, it could still theoretically happen, and the consequence is very bad. This issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260719155442.88794-1-sj@kernel.org Link: https://lore.kernel.org/20260717011834.120715-1-sj@kernel.org [1] Fixes: b1029f29eb1d ("mm/damon/core: split regions for min_nr_regions") Signed-off-by: SJ Park Cc: # 7.1.x Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

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

2026-09-11T09:50:50+00:00

commit 488cf81c49955f83b7682dda880e9920c173e617 upstream. 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 Signed-off-by: Greg Kroah-Hartman

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

2026-09-11T09:50:50+00:00

commit 867bbe6dbd5a68eb58e79cc7f068a6cf184c40d8 upstream. 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 Signed-off-by: Greg Kroah-Hartman

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

2026-09-11T09:50:50+00:00

commit 7e2f2c41b27f64caad6599073aaa0ccdd08745e1 upstream. 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 Signed-off-by: Greg Kroah-Hartman

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

2026-09-11T09:50:50+00:00

commit 3423fe70395210e2f0cd795270292f6a27cd57b5 upstream. 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 Signed-off-by: Greg Kroah-Hartman