[PATCH 0/2] mm/damon: fix wrong behaviors in DAMOS PSI goal and sysfs refresh_ms

[PATCH 0/2] mm/damon: fix wrong behaviors in DAMOS PSI goal and sysfs refresh_ms

[SJ Park]

PSI based DAMOS auto-tuning and DAMON sysfs refresh_ms file have bugs
that can produce non critical but still unexpected behaviors.  Fix the
two bugs.

SJ Park (2):
  mm/damon/core: initialize damos_quota_goal->last_psi_total
  mm/damon/sysfs: set next refresh jiffies per sysfs context

 mm/damon/core.c  | 16 +++++++++++++++-
 mm/damon/sysfs.c | 11 +++++------
 2 files changed, 20 insertions(+), 7 deletions(-)


base-commit: 3b3eb2976e2dadfd8624db7ba32ed28addb7e416
-- 
2.47.3

[PATCH 1/2] mm/damon/core: initialize damos_quota_goal->last_psi_total

[SJ Park]

When DAMOS_QUOTA_SOME_MEM_PSI_US metric damos quota goal is set, the PSI
delta for the feedback loop is calculated using
damos_quota_goal->last_psi_total.  However, it is initialized only after
the first feedback loop.  The first iteration of the loop uses the
uninitialized value.  As a result, the feedback loop can change the
effective quota in an unexpected way at the first iteration.

The user impact of the issue is not big, because the issue impacts only
the first iteration of the feedback loop.  The feedback loop also has an
internal cap of the quota adjustment.  The wrong adjustment will soon be
corrected over a few iterations.  For this reason, doing no
initialization at commit time was intentional.  It is also explicitly
commented.  That said, nobody likes behaviors that are unexpected or
difficult to be expected.  Fixing it is also simple and not expensive.

Initialize the field at the beginning of kdamond and each commit of
SOME_MEM_PSI_US type quota goals.

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/20260718005316.89585-1-sj@kernel.org

Fixes: 2dbb60f789cb ("mm/damon/core: implement PSI metric DAMOS quota goal")
Cc: <stable@vger.kernel.org> # 6.9.x
Signed-off-by: SJ Park <sj@kernel.org>
---
 mm/damon/core.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/mm/damon/core.c b/mm/damon/core.c
index f8dddbff74a77..0d4a571482fb9 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -1122,6 +1122,9 @@ static void damos_commit_quota_goal_union(
 		struct damos_quota_goal *dst, struct damos_quota_goal *src)
 {
 	switch (dst->metric) {
+	case DAMOS_QUOTA_SOME_MEM_PSI_US:
+		dst->last_psi_total = damos_get_some_mem_psi_total();
+		break;
 	case DAMOS_QUOTA_NODE_MEM_USED_BP:
 	case DAMOS_QUOTA_NODE_MEM_FREE_BP:
 		dst->nid = src->nid;
@@ -1143,7 +1146,6 @@ static void damos_commit_quota_goal(
 	dst->target_value = src->target_value;
 	if (dst->metric == DAMOS_QUOTA_USER_INPUT)
 		dst->current_value = src->current_value;
-	/* keep last_psi_total as is, since it will be updated in next cycle */
 	damos_commit_quota_goal_union(dst, src);
 }
 
@@ -3741,6 +3743,17 @@ static int kdamond_wait_activation(struct damon_ctx *ctx)
 	return -EBUSY;
 }
 
+static void damos_init_quota_goal_last_psi(struct damos *s)
+{
+	struct damos_quota_goal *goal;
+
+	damos_for_each_quota_goal(goal, &s->quota) {
+		if (goal->metric != DAMOS_QUOTA_SOME_MEM_PSI_US)
+			continue;
+		goal->last_psi_total = damos_get_some_mem_psi_total();
+	}
+}
+
 static void kdamond_init_ctx(struct damon_ctx *ctx)
 {
 	unsigned long sample_interval = ctx->attrs.sample_interval ?
@@ -3757,6 +3770,7 @@ static void kdamond_init_ctx(struct damon_ctx *ctx)
 	damon_for_each_scheme(scheme, ctx) {
 		damos_set_next_apply_sis(scheme, ctx);
 		damos_set_filters_default_reject(scheme);
+		damos_init_quota_goal_last_psi(scheme);
 	}
 }
 
-- 
2.47.3

[PATCH 2/2] mm/damon/sysfs: set next refresh jiffies per sysfs context

[SJ Park]

When 'refresh_ms' is set, DAMON sysfs interface periodically updates
auto-tuned parameters and DAMOS stats.  The timestamp for the next
refresh is initialized when a DAMON context starts, and updated in its
damon_call() callback function.  That is, each DAMON context updates it.
However, the timestamp is a global variable that is shared with all the
contexts.  When there are multiple DAMON contexts having different
refresh_ms, the update frequency will be changed, depending on the order
of the contexts.  When there are multiple kdamonds, it will be even more
chaotic.  Fix the problem by having the timestamp per each context.

The user impact is not very critical.  It does not leak, corrupt or
crash.  The update will not be faster or slower than the lowest and
largest refresh_ms values of the contexts, respectively.  The user can
also manually ask the updates on demand using kdamond state commands.
That said, clearly this is a bug.

Fixes: 9fd7bb5083d1 ("mm/damon/sysfs: change next_update_jiffies to a global variable")
Cc: <stable@vger.kernel.org> # 6.18.x
Signed-off-by: SJ Park <sj@kernel.org>
---
 mm/damon/sysfs.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/mm/damon/sysfs.c b/mm/damon/sysfs.c
index e3858ffab4b22..f05b256c90ee7 100644
--- a/mm/damon/sysfs.c
+++ b/mm/damon/sysfs.c
@@ -1789,6 +1789,7 @@ struct damon_sysfs_kdamond {
 	struct damon_sysfs_contexts *contexts;
 	struct damon_ctx *damon_ctx;
 	unsigned int refresh_ms;
+	unsigned long next_refresh_jiffies;
 };
 
 static struct damon_sysfs_kdamond *damon_sysfs_kdamond_alloc(void)
@@ -2215,17 +2216,15 @@ static struct damon_ctx *damon_sysfs_build_ctx(
 	return ctx;
 }
 
-static unsigned long damon_sysfs_next_update_jiffies;
-
 static int damon_sysfs_repeat_call_fn(void *data)
 {
 	struct damon_sysfs_kdamond *sysfs_kdamond = data;
 
 	if (!sysfs_kdamond->refresh_ms)
 		return 0;
-	if (time_before(jiffies, damon_sysfs_next_update_jiffies))
+	if (time_before(jiffies, sysfs_kdamond->next_refresh_jiffies))
 		return 0;
-	damon_sysfs_next_update_jiffies = jiffies +
+	sysfs_kdamond->next_refresh_jiffies = jiffies +
 		msecs_to_jiffies(sysfs_kdamond->refresh_ms);
 
 	if (!mutex_trylock(&damon_sysfs_lock))
@@ -2273,8 +2272,8 @@ static int damon_sysfs_turn_damon_on(struct damon_sysfs_kdamond *kdamond)
 	}
 	kdamond->damon_ctx = ctx;
 
-	damon_sysfs_next_update_jiffies =
-		jiffies + msecs_to_jiffies(kdamond->refresh_ms);
+	kdamond->next_refresh_jiffies = jiffies +
+		msecs_to_jiffies(kdamond->refresh_ms);
 
 	repeat_call_control->fn = damon_sysfs_repeat_call_fn;
 	repeat_call_control->data = kdamond;
-- 
2.47.3

Re: [PATCH 2/2] mm/damon/sysfs: set next refresh jiffies per sysfs context

[sashiko-bot]

> When 'refresh_ms' is set, DAMON sysfs interface periodically updates
> auto-tuned parameters and DAMOS stats.  The timestamp for the next
> refresh is initialized when a DAMON context starts, and updated in its
> damon_call() callback function.  That is, each DAMON context updates it.
> However, the timestamp is a global variable that is shared with all the
> contexts.  When there are multiple DAMON contexts having different
> refresh_ms, the update frequency will be changed, depending on the order
> of the contexts.  When there are multiple kdamonds, it will be even more
> chaotic.  Fix the problem by having the timestamp per each context.
> 
> The user impact is not very critical.  It does not leak, corrupt or
> crash.  The update will not be faster or slower than the lowest and
> largest refresh_ms values of the contexts, respectively.  The user can
> also manually ask the updates on demand using kdamond state commands.
> That said, clearly this is a bug.
> 
> Fixes: 9fd7bb5083d1 ("mm/damon/sysfs: change next_update_jiffies to a global variable")
> Cc: <stable@vger.kernel.org> # 6.18.x
> Signed-off-by: SJ Park <sj@kernel.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260827042920.93580-1-sj@kernel.org?part=2

Re: [PATCH 0/2] mm/damon: fix wrong behaviors in DAMOS PSI goal and sysfs refresh_ms

[SJ Park]

My intention was to send this as an RFC series.  I forgot adding 'RFC' tag by a
mistake.  Sorry for noise.  Andrew, could you please drop this series from
mm-new for now?


Thanks,
SJ

[...]

Re: [PATCH 1/2] mm/damon/core: initialize damos_quota_goal->last_psi_total

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Low] Implicit declaration of function 'damos_get_some_mem_psi_total' causes a compilation error.

Pre-existing issues:
- [High] The DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP metric's 'nid' field is not copied when committing a quota goal parameter update, leading to an uninitialized node ID being used for eligible memory queries.
--

commit 9597a197ecbd4f36e4fa8dfa9bd1bdbb5a5f1d93
Author: SJ Park <sj@kernel.org>

mm/damon/core: initialize damos_quota_goal->last_psi_total

Initializes the last_psi_total field at the beginning of kdamond and during
each commit for SOME_MEM_PSI_US type quota goals. This prevents unexpected
adjustments during the first iteration of the feedback loop.

Link: https://lore.kernel.org/20260718005316.89585-1-sj@kernel.org

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 644daf5a16560..6f360d61390ad 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -1122,6 +1122,9 @@ static void damos_commit_quota_goal_union(
>  		struct damos_quota_goal *dst, struct damos_quota_goal *src)
>  {
>  	switch (dst->metric) {
> +	case DAMOS_QUOTA_SOME_MEM_PSI_US:
> +		dst->last_psi_total = damos_get_some_mem_psi_total();

[Severity: Low]
Does this cause a compilation error due to an implicit function declaration?

The function damos_get_some_mem_psi_total() is called here, but it appears
to be defined later in mm/damon/core.c without a prior forward declaration.

> +		break;
>  	case DAMOS_QUOTA_NODE_MEM_USED_BP:
>  	case DAMOS_QUOTA_NODE_MEM_FREE_BP:
>  		dst->nid = src->nid;

[Severity: High]
This is a pre-existing issue, but does this switch statement omit the
DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP metric?

When a user configures a DAMOS quota goal using the
DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP metric via sysfs, a new quota goal is
allocated in damos_new_quota_goal() via kmalloc_obj(), where the memory is
not zeroed. 

Because DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP is missing from the switch statement
in damos_commit_quota_goal_union(), its nid field is not copied over during
parameter updates. This leaves the node ID uninitialized and potentially
causes eligible memory queries to evaluate using garbage data, completely
breaking the metric's functionality.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260827042920.93580-1-sj@kernel.org?part=1

Re: [PATCH 1/2] mm/damon/core: initialize damos_quota_goal->last_psi_total

[SJ Park]

On Thu, 27 Aug 2026 04:45:47 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> 
> New issues:
> - [Low] Implicit declaration of function 'damos_get_some_mem_psi_total' causes a compilation error.
> 
> Pre-existing issues:
> - [High] The DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP metric's 'nid' field is not copied when committing a quota goal parameter update, leading to an uninitialized node ID being used for eligible memory queries.
> --
> 
> commit 9597a197ecbd4f36e4fa8dfa9bd1bdbb5a5f1d93
> Author: SJ Park <sj@kernel.org>
> 
> mm/damon/core: initialize damos_quota_goal->last_psi_total
> 
> Initializes the last_psi_total field at the beginning of kdamond and during
> each commit for SOME_MEM_PSI_US type quota goals. This prevents unexpected
> adjustments during the first iteration of the feedback loop.
> 
> Link: https://lore.kernel.org/20260718005316.89585-1-sj@kernel.org
> 
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > index 644daf5a16560..6f360d61390ad 100644
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> > @@ -1122,6 +1122,9 @@ static void damos_commit_quota_goal_union(
> >  		struct damos_quota_goal *dst, struct damos_quota_goal *src)
> >  {
> >  	switch (dst->metric) {
> > +	case DAMOS_QUOTA_SOME_MEM_PSI_US:
> > +		dst->last_psi_total = damos_get_some_mem_psi_total();
> 
> [Severity: Low]
> Does this cause a compilation error due to an implicit function declaration?
> 
> The function damos_get_some_mem_psi_total() is called here, but it appears
> to be defined later in mm/damon/core.c without a prior forward declaration.

Good catch.  I will add the declaration in the next version.

> 
> > +		break;
> >  	case DAMOS_QUOTA_NODE_MEM_USED_BP:
> >  	case DAMOS_QUOTA_NODE_MEM_FREE_BP:
> >  		dst->nid = src->nid;
> 
> [Severity: High]
> This is a pre-existing issue, but does this switch statement omit the
> DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP metric?
> 
> When a user configures a DAMOS quota goal using the
> DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP metric via sysfs, a new quota goal is
> allocated in damos_new_quota_goal() via kmalloc_obj(), where the memory is
> not zeroed. 
> 
> Because DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP is missing from the switch statement
> in damos_commit_quota_goal_union(), its nid field is not copied over during
> parameter updates. This leaves the node ID uninitialized and potentially
> causes eligible memory queries to evaluate using garbage data, completely
> breaking the metric's functionality.

Good catch.  I will separately work on this.

> 
> [ ... ]
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260827042920.93580-1-sj@kernel.org?part=1


Thanks,
SJ

Re: [PATCH 1/2] mm/damon/core: initialize damos_quota_goal->last_psi_total

[SJ Park]

On Wed, 26 Aug 2026 21:50:34 -0700 SJ Park <sj@kernel.org> wrote:

> On Thu, 27 Aug 2026 04:45:47 +0000 sashiko-bot@kernel.org wrote:
[...]
> > [Severity: High]
> > This is a pre-existing issue, but does this switch statement omit the
> > DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP metric?
> > 
> > When a user configures a DAMOS quota goal using the
> > DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP metric via sysfs, a new quota goal is
> > allocated in damos_new_quota_goal() via kmalloc_obj(), where the memory is
> > not zeroed. 
> > 
> > Because DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP is missing from the switch statement
> > in damos_commit_quota_goal_union(), its nid field is not copied over during
> > parameter updates. This leaves the node ID uninitialized and potentially
> > causes eligible memory queries to evaluate using garbage data, completely
> > breaking the metric's functionality.
> 
> Good catch.  I will separately work on this.

Actually the fix will be quite straightforward.  I will add that as a part of
the next version of this series.


Thanks,
SJ

[...]