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.

Changes from v1
- v1: https://lore.kernel.org/20260714135236.92699-1-sj@kernel.org
- Add addr_unit race fix.
- Add Fixes: tags to the race fixes.
- Wordsmith subjects.
Changes from RFC v1.2
- RFC v1.2: https://lore.kernel.org/20260713135838.32730-1-sj@kernel.org
- Drop RFC tag.
- Rebase to latest mm-new.
Changes from RFC v1.1
- RFC v1.1: https://lore.kernel.org/20260712170328.91144-1-sj@kernel.org
- Remove same_target param from __damon_va_check_access().
Changes from RFC
- RFC: https://lore.kernel.org/20260711180409.82093-1-sj@kernel.org
- Rebase to mm-new.

SJ Park (6):
  mm/damon/core: avoid infinite kdamond_merge_regions() internal loop
  mm/damon/tests/core-kunit: catch test failure in
    test_merge_regions_of()
  mm/damon/vaddr: drop last same folio access check optimization
  mm/damon/paddr: drop last same folio access check reuse optimization
  mm/damon/sysfs: read addr_unit only once in damon_sysfs_apply_inputs()
  mm/damon/sysfs: read ops_id only once in damon_sysfs_apply_inputs()

 mm/damon/core.c             | 13 +++++++++----
 mm/damon/paddr.c            | 20 ++++----------------
 mm/damon/sysfs.c            | 10 ++++++----
 mm/damon/tests/core-kunit.h |  3 +++
 mm/damon/vaddr.c            | 33 ++++++---------------------------
 5 files changed, 28 insertions(+), 51 deletions(-)


base-commit: 52d335d2c1de60b6184b9de5ecec634892a3e136
-- 
2.47.3

On Tue, 14 Jul 2026 20:09:55 -0700 SJ Park <sj@kernel.org> wrote:

> 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.

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

[...]

On Tue, 14 Jul 2026 20:09:55 -0700 SJ Park <sj@kernel.org> wrote:

> 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.

> Subject: [PATCH v1.1 0/6] ...

So... what is the significance of "1.1" here?

On Tue, 14 Jul 2026 21:46:04 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:

> On Tue, 14 Jul 2026 20:09:55 -0700 SJ Park <sj@kernel.org> wrote:
> 
> > 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.
> 
> > Subject: [PATCH v1.1 0/6] ...
> 
> So... what is the significance of "1.1" here?

As the changelog says, one more unurgent fix (patch 5 of this sereis) has added
on top of the v1.

Maybe my versioning scheme is confusing you.  I increase minor version when it
is purely for findings from Sashiko and if the change seems not really big.  I
do so because I realized it is easy to get version number large in short term
when I respect Sashiko, and it may look confusing for some people.  Maybe a
better approach is running Sashiko in my local, but I don't have AI setup in my
development environment...  Let me know if this only confuses and bothers you
and you have a suggestion.


Thanks,
SJ