mm/damon: allow NULL or unstarted damon_ctx parameter for damon_call()

When NULL damon_ctx pointer parameter is passed, damon_call() could do NULL dereference. The caller is responsible to avoid that. It is easy to forget, and there are many damon_call() callers. Meanwhile, damon_call() is never meant to be performance critical. It uses mutex and completion. Add the NULL pointer check inside damon_call() so that callers can pass the parameter without NULL checks.

Signed-off-by SJ Park <[email protected]>

---
 mm/damon/core.c | 2 ++
 1 file changed, 2 insertions(+)

mm/damon/core.c +0 -0

index 92631a36d7b51..5882f9c94c47f 100644

Hi SJ,

Quoted 17 lines · SJ Park

When NULL damon_ctx pointer parameter is passed, damon_call() could do NULL dereference. The caller is responsible to avoid that. It is easy to forget, and there are many damon_call() callers. Meanwhile, damon_call() is never meant to be performance critical. It uses mutex and completion. Add the NULL pointer check inside damon_call() so that callers can pass the parameter without NULL checks.

Signed-off-by SJ Park <[email protected]>

---
 mm/damon/core.c | 2 ++
 1 file changed, 2 insertions(+)

mm/damon/core.c +0 -0

index 92631a36d7b51..5882f9c94c47f 100644

mm/damon/core.c int damon_kdamond_pid(struct damon_ctx *ctx) · line 2195

Quoted 8 lines

mm/damon/core.c +2 -0

@@ -2188,6 +2188,8 @@ int damon_kdamond_pid(struct damon_ctx *ctx)
  */
 int damon_call(struct damon_ctx *ctx, struct damon_call_control *control)
 {
+	if (!ctx)
+		return -EINVAL;
 	if (!control->repeat)
 		init_completion(&control->completion);
 	control->canceled = false;

I know that this is a minor optimization, but how about moving INIT_LIST_HEAD(&control->list) to right before list_add_tail?

It doesn't make sense to initialize the list before checking call_controls_obsolete.

Maybe this suggestion should go in a different patch.

Hi Asier,

Thank you for your review!

Quoted 32 lines · On Thu, 13 Aug 2026 11:33:01 +0300 Gutierrez Asier…

Hi SJ,

Quoted 17 lines · SJ Park

When NULL damon_ctx pointer parameter is passed, damon_call() could do NULL dereference. The caller is responsible to avoid that. It is easy to forget, and there are many damon_call() callers. Meanwhile, damon_call() is never meant to be performance critical. It uses mutex and completion. Add the NULL pointer check inside damon_call() so that callers can pass the parameter without NULL checks.

Signed-off-by SJ Park <[email protected]>

---
 mm/damon/core.c | 2 ++
 1 file changed, 2 insertions(+)

mm/damon/core.c +0 -0

index 92631a36d7b51..5882f9c94c47f 100644

mm/damon/core.c int damon_kdamond_pid(struct damon_ctx *ctx) · line 2195

Quoted 8 lines

mm/damon/core.c +2 -0

@@ -2188,6 +2188,8 @@ int damon_kdamond_pid(struct damon_ctx *ctx)
  */
 int damon_call(struct damon_ctx *ctx, struct damon_call_control *control)
 {
+	if (!ctx)
+		return -EINVAL;
 	if (!control->repeat)
 		init_completion(&control->completion);
 	control->canceled = false;

I know that this is a minor optimization, but how about moving INIT_LIST_HEAD(&control->list) to right before list_add_tail?

Quoted 1 line

It doesn't make sense to initialize the list before checking call_controls_obsolete.

I agree it might be more efficient.

I think my intention of the code was to to keep the call_controls_lock critical section minimal with access to things that really protected by the mutex. Moving the simple initialization should be fine. As you mentioned, it should be minor change. I'm bit concerned if it will confuse people if the list head is also protected by the mutex, though. What do you think?

Quoted 3 lines

Maybe this suggestion should go in a different patch.

I agree.

Thanks,
SJ

[...]

Quoted 41 lines · SJ Park

Hi Asier,

Thank you for your review!

Quoted 32 lines · On Thu, 13 Aug 2026 11:33:01 +0300 Gutierrez Asier…

Hi SJ,

Quoted 17 lines · SJ Park

When NULL damon_ctx pointer parameter is passed, damon_call() could do NULL dereference. The caller is responsible to avoid that. It is easy to forget, and there are many damon_call() callers. Meanwhile, damon_call() is never meant to be performance critical. It uses mutex and completion. Add the NULL pointer check inside damon_call() so that callers can pass the parameter without NULL checks.

Signed-off-by SJ Park <[email protected]>

---
 mm/damon/core.c | 2 ++
 1 file changed, 2 insertions(+)

mm/damon/core.c +0 -0

index 92631a36d7b51..5882f9c94c47f 100644

mm/damon/core.c int damon_kdamond_pid(struct damon_ctx *ctx) · line 2195

Quoted 8 lines

mm/damon/core.c +2 -0

@@ -2188,6 +2188,8 @@ int damon_kdamond_pid(struct damon_ctx *ctx)
  */
 int damon_call(struct damon_ctx *ctx, struct damon_call_control *control)
 {
+	if (!ctx)
+		return -EINVAL;
 	if (!control->repeat)
 		init_completion(&control->completion);
 	control->canceled = false;

I know that this is a minor optimization, but how about moving INIT_LIST_HEAD(&control->list) to right before list_add_tail?

Quoted 1 line

It doesn't make sense to initialize the list before checking call_controls_obsolete.

Quoted 7 lines

I agree it might be more efficient.

I think my intention of the code was to to keep the call_controls_lock critical section minimal with access to things that really protected by the mutex. Moving the simple initialization should be fine. As you mentioned, it should be minor change. I'm bit concerned if it will confuse people if the list head is also protected by the mutex, though. What do you think?

Good point, I didn't think about it.

Given that damon_call is not called often, I believe user experience should be more important than efficiency. Anyway, you have the last word.

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch introduces an inconsistent state in the damon_ctx API by initializing call_controls_obsolete to true while leaving its identically-designed sibling field walk_control_obsolete as false. --

--- Patch [2]: [RFC PATCH 2/4] mm/damon/core: set ctx->call_controls_obsolete in damon_new_ctx() --- commit 94c12d6bfcca8f83b408960a36d0c0a8519d80c7
Author: SJ Park <[email protected]>

mm/damon/core: set ctx->call_controls_obsolete in damon_new_ctx()

This commit addresses an issue where passing an unstarted DAMON context to damon_call() can cause an indefinite hang. It fixes this by initializing ctx->call_controls_obsolete to true in damon_new_ctx().

Link https://lore.kernel.org/[email protected] open here

mm/damon/core.c struct damon_ctx *damon_new_ctx(void) · line 867

Quoted 9 lines

mm/damon/core.c +1 -0

index af7b77710745d..5080cb12220d2 100644
@@ -864,6 +864,7 @@ struct damon_ctx *damon_new_ctx(void)
 	INIT_LIST_HEAD(&ctx->adaptive_targets);
 	INIT_LIST_HEAD(&ctx->schemes);
 
+	ctx->call_controls_obsolete = true;

[Severity: Medium]
Should ctx->walk_control_obsolete also be initialized to true here?

Because walk_control_obsolete is zero-initialized to false during allocation, an unstarted context passed to damos_walk() will bypass the obsolete check:

mm/damon/core.c:damos_walk() {
	...
	if (ctx->walk_control_obsolete) {
		mutex_unlock(&ctx->walk_control_lock);
		return -ECANCELED;
	}
	...
}

This appears to leave damos_walk() vulnerable to the exact same indefinite wait_for_completion() hang on unstarted contexts that this patch resolves for damon_call().

Does it make sense to update walk_control_obsolete alongside call_controls_obsolete to ensure the API behaves consistently?

Quoted 4 lines

mm/damon/core.c +0 -0

 	prandom_seed_state(&ctx->rnd_state, get_random_u64());
 
 	return ctx;

[ ... ]

Signature · 1 line

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2

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

Pre-existing issues:
- [High] Concurrent invocation of damon_call() during kthread startup leads to an infinite kernel loop. --

--- Patch [3]: [RFC PATCH 3/4] mm/damon/reclaim: remove unnecessary damon_call() param validation --- commit 07f6c5438f6069b0b8225e26e3726d6aa4e3da09
Author: SJ Park <[email protected]>

mm/damon/reclaim: remove unnecessary damon_call() param validation

DAMON_RECLAIM avoids passing NULL or unstarted damon_ctx to damon_call() with its own validation. The validation is no longer needed, because the DAMON core layer now handles the corner cases itself. Remove the unnecessary check.

Quoted 4 lines

mm/damon/reclaim.c +0 -0

index 45d5557cc575a..42a2c9cb13431 100644

[ ... ]

mm/damon/reclaim.c static int damon_reclaim_commit_inputs_store(const char *val, · line 299

Quoted 8 lines

mm/damon/reclaim.c +0 -4

@@ -293,10 +291,6 @@ static int damon_reclaim_commit_inputs_store(const char *val,
 	if (!commit_inputs_request)
 		return 0;
 
-	/* Skip damon_call() if ctx has not successfully started. */
-	if (!damon_reclaim_damon_has_started)
-		return -EINVAL;
-

[Severity: High]
This is a pre-existing issue, but does removing this validation expose an infinite loop in the DAMON core?

If userspace writes to this sysfs file concurrently with damon_start(), damon_call() in mm/damon/core.c can hit a race condition. The core initializes ctx->call_controls_obsolete to true. If damon_call() runs before the kthread fully starts, it can read call_controls_obsolete == true and jump to the canceled label:

mm/damon/core.c:damon_call() {
    ...
    if (ctx->call_controls_obsolete) {
        mutex_unlock(&ctx->call_controls_lock);
        goto canceled;
    }
    ...
canceled:
    while (damon_is_running(ctx))
        schedule_timeout_idle(msecs_to_jiffies(100));
    return -ECANCELED;
}

If damon_start() concurrently sets ctx->kdamond to non-NULL, damon_is_running(ctx) becomes true. Because the kthread has just started, it runs indefinitely, and damon_call() gets trapped in the while loop forever.

Quoted 4 lines

mm/damon/reclaim.c +0 -0

 	err = damon_call(ctx, &control);
 
 	return err ? err : control.return_code;

Signature · 1 line

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Removing the damon_lru_sort_damon_has_started check exposes a race condition causing an infinite loop in damon_call() when invoked concurrently during kdamond startup. --

--- Patch [4]: [RFC PATCH 4/4] mm/damon/lru_sort: remove unnecessary damon_call() param validation --- commit 288d310b5c3c2bd758d5db8eef7c717db03cbd01
Author: SJ Park <[email protected]>

mm/damon/lru_sort: remove unnecessary damon_call() param validation

This commit removes custom validation in damon_lru_sort_commit_inputs_store that checked if the damon context had successfully started before calling damon_call. The commit message states this is safe because the damon core layer now handles these corner cases.

Quoted 4 lines

mm/damon/lru_sort.c +0 -0

index bd847829a9907..f25ee7326e87c 100644

[ ... ]

mm/damon/lru_sort.c static int damon_lru_sort_commit_inputs_store(const char *val, · line 369

Quoted 9 lines

mm/damon/lru_sort.c +0 -4

@@ -368,10 +366,6 @@ static int damon_lru_sort_commit_inputs_store(const char *val,
 	if (!commit_inputs_request)
 		return 0;
 
-	/* Skip damon_call() if ctx has not successfully started. */
-	if (!damon_lru_sort_damon_has_started)
-		return -EINVAL;
-
 	err = damon_call(ctx, &control);

[Severity: High]
Does removing this safeguard expose a race condition causing an infinite loop in damon_call when invoked concurrently during kdamond startup?

If a user writes to the enabled sysfs file to start the daemon, and concurrently writes to commit_inputs, damon_call can execute while damon_start is waiting for kdamond to fully initialize.

In this scenario, damon_call could read ctx->call_controls_obsolete == true (since the kdamond thread hasn't cleared it yet) and jump to the canceled path:

mm/damon/core.c:damon_call() {
    ...
canceled:
	while (damon_is_running(ctx))
		schedule_timeout_idle(msecs_to_jiffies(100));
	return -ECANCELED;
}

Because the daemon thread has already been spawned and assigned, making damon_is_running persistently true, won't this loop indefinitely, hanging the sysfs writer process?

Quoted 3 lines

mm/damon/lru_sort.c +0 -0

 	return err ? err : control.return_code;

Signature · 1 line

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=4