[BUG] DAMON sysfs: failed update clears tried_regions snapshot

[BUG] DAMON sysfs: failed update clears tried_regions snapshot

[Aveline Noir]

Hi,

On mm-new commit ad9f2d463666, requesting
update_schemes_tried_regions after stopping a kdamond returns
-ECANCELED and clears the previous tried_regions snapshot.  The final
result collected before "off" is then lost.

I reproduced this in an x86_64 QEMU guest running
7.3.0-rc5-1485016-gad9f2d463666.  It used one PADDR context over
[0x400000, 0x800000) and one default stat scheme.  The paths below are
relative to /sys/kernel/mm/damon/admin/kdamonds/0/:

  ../nr_kdamonds = 1
  contexts/nr_contexts = 1
  contexts/0/operations = paddr
  contexts/0/targets/nr_targets = 1
  contexts/0/targets/0/regions/nr_regions = 1
  contexts/0/targets/0/regions/0/start = 4194304
  contexts/0/targets/0/regions/0/end = 8388608
  contexts/0/schemes/nr_schemes = 1
  contexts/0/schemes/0/access_pattern/{sz,nr_accesses,age}/max =
      4294967295 for each file

The reproducer then:

  1. Wrote "on" and "update_schemes_tried_regions" to state.
  2. Read contexts/0/schemes/0/tried_regions/total_bytes and counted
     the region directories there.
  3. Wrote "off" to state, then requested
     "update_schemes_tried_regions" again and read the same results.

The guest output was:

  BEFORE_OFF bytes=4194304 dirs=10
  STATE_OFF bytes=4194304 dirs=10
  FAILED_UPDATE ret=-1 errno=125 bytes_after=0 dirs_after=0

errno 125 is ECANCELED.  The snapshot survives "off", but the failed
update removes all 10 directories and resets total_bytes.  There is a
separate clear_schemes_tried_regions command for clearing a snapshot;
a failed update should leave the last successful one available.

damon_sysfs_turn_damon_off() retains damon_ctx for final results.  But
damon_sysfs_update_schemes_tried_regions() calls
damon_sysfs_schemes_clear_regions() before damos_walk().  Once the
context is stopped, damos_walk() returns -ECANCELED because its walk
control is obsolete, leaving the sysfs results cleared.

The guest completed with RESULT exit=0.  Reproducer, kernel config,
serial log, and build/run steps:

  https://github.com/jm5905938/kernel-mail/tree/195d7017352a3d0f4a0475b98f3b03650f5c14ea/cases/2026/damon/2026-10-15-bug-reports/01-sysfs-tried-regions-snapshot

Thanks,
Aveline Noir

Re: [BUG] DAMON sysfs: failed update clears tried_regions snapshot

[SJ Park]

Hi Avelin,

On Thu, 15 Oct 2026 07:22:38 -0400 Aveline Noir <jm5905938@gmail.com> wrote:

> Hi,
> 
> On mm-new commit ad9f2d463666, requesting
> update_schemes_tried_regions after stopping a kdamond returns
> -ECANCELED and clears the previous tried_regions snapshot.  The final
> result collected before "off" is then lost.

Could you further share your use case that this behavior becomes a real
problem?  Also, have you tried bisecting this to find from when this behavior
was introduced?  If so, could you share the commit that introduced this
behavior?


THanks,
SJ

[...]

Re: [BUG] DAMON sysfs: failed update clears tried_regions snapshot

[Aveline Noir]

Hi SJ,

I haven't seen this affect a real workload. I found it while testing
the DAMON sysfs interface.

If a tool tries to refresh after monitoring stops, the failed request
can delete the last snapshot. The tool then has no previous result to
fall back to.

I built and tested 66178e4ec30a and its parent cce0b334c310 with the
same config and reproducer. In three runs each, the parent kept the
4 MiB snapshot after rejecting the refresh; 66178e4ec30a cleared it.
Both returned -EINVAL.

Thanks,
Aveline Noir


On Thu, 15 Oct 2026 07:05:01 -0700, SJ Park <sj@kernel.org> wrote:
> Hi Avelin,
>
> On Thu, 15 Oct 2026 07:22:38 -0400 Aveline Noir <jm5905938@gmail.com> wrote:
>
> > Hi,
> >
> > On mm-new commit ad9f2d463666, requesting
> > update_schemes_tried_regions after stopping a kdamond returns
> > -ECANCELED and clears the previous tried_regions snapshot.  The final
> > result collected before "off" is then lost.
>
> Could you further share your use case that this behavior becomes a real
> problem?  Also, have you tried bisecting this to find from when this behavior
> was introduced?  If so, could you share the commit that introduced this
> behavior?
>
>
> THanks,
> SJ
>
> [...]

Re: [BUG] DAMON sysfs: failed update clears tried_regions snapshot

[SJ Park]

Hi Aveline,


Please do not "top-post" [1].

On Thu, 15 Oct 2026 10:17:05 -0500 Aveline Noir <jm5905938@gmail.com> wrote:

> Hi SJ,
> 
> I haven't seen this affect a real workload. I found it while testing
> the DAMON sysfs interface.

You shared 4 bug reports in very short time.  Three of those are from 32 bit.
Could you disclose the purpose of the testing and how you are doing the
testing, finding bugs, and reporting those?

> 
> If a tool tries to refresh after monitoring stops, the failed request
> can delete the last snapshot. The tool then has no previous result to
> fall back to.

Why would the tool tries to refresh the regions after the monitoring is
stopped?

> 
> I built and tested 66178e4ec30a and its parent cce0b334c310 with the
> same config and reproducer. In three runs each, the parent kept the
> 4 MiB snapshot after rejecting the refresh; 66178e4ec30a cleared it.
> Both returned -EINVAL.

Is this an answer to my bisection question?

[1] https://subspace.kernel.org/etiquette.html#do-not-top-post-when-replying


Thanks,
SJ

[...]

Re: [BUG] DAMON sysfs: failed update clears tried_regions snapshot

[Aveline Noir]

Hi SJ,

> Please do not "top-post" [1].

Sorry about that. I'll avoid top-posting from now on : (

> You shared 4 bug reports in very short time. Three of those are
> from 32 bit.
> Could you disclose the purpose of the testing and how you are
> doing the testing, finding bugs, and reporting those?

I've been trying to understand DAMON in more depth with help from
an LLM, not deliberately hunting for bugs. It spotted a few possible
problems as we went through the code. After checking the code and
reproducing them in QEMU, I thought they were worth reporting.
If that wasn't the right way to go about it, please let me know :)

> Why would the tool tries to refresh the regions after the monitoring
> is stopped?

That's probably not something normal users would do. The test
deliberately called the update after monitoring stopped and found
that the failed request cleared the old snapshot. It looked
unexpected, so I reported it to ask whether that's intended.

> Is this an answer to my bisection question?

No, that wasn't a `git bisect` run. The suspect commit,
`66178e4ec30a`, came from code review. I tested it and its
parent `cce0b334c310` with the same setup. The parent kept
the snapshot, but the newer commit cleared it.

Thx for your time, and sorry if I've caused any trouble:(

Best,
Aveline