[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

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

[SJ Park]

On Thu, 15 Oct 2026 19:12:25 -0700 Aveline Noir <jm5905938@gmail.com> wrote:

> Hi SJ,
> 
> > Please do not "top-post" [1].
> 
> Sorry about that. I'll avoid top-posting from now on : (

No worry, nobody knows everything from the beginning, and we all learn from
mistakes.

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

That makes sense, thank you for sharing the context.

> If that wasn't the right way to go about it, please let me know :)

That's the right way.  Nonetheless, disclosing this kind of information is very
helpful.  Particularly nowadays, use of AI-like tools is nearly always better
to disclose.  It is not because maintainers hate AI.  It is because AI-like
tools are still something new that sometimes good but also do mistake, and
therefore maintainers are still learning the tools.  I'd suggest disclosing
this kind of context in your future contexts, not only for DAMON, but for
kernel works in general.

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

Makes sense.  So I think this is not DAMON implementation problem.  Tools
should aware this and do not try refreshing when the kdamond is terminated, or
remember old snapshot.

If this behavior is not documented, that's documentation issue that we shold
fix.  Please feel free to send a patch for documenting, if you don't mind.  If
DAMON user-space tool is not aware of this and give users unexpected results,
please feel free to send a PR for fixing it, if you don't mind.

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

Ok, that makes sense.  Thank you for letting me know this.  So, this is a
behavior that changed from that of the past.  But I still feel the current
behavior is not a real problem.  In a sense, if the kdamond is terminated, it
has no region and therefore showing no region makes sense to me.  Please let me
know if I'm missing something or you have other opinions.

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

No worries.  I'm also sorry if you felt you are suspected or not welcomed.  I
believe now we are all good and you are welcomed.  Thank you for kindly
answering all my questions.


Thanks,
SJ

[...]