Re: (sashiko review) [PATCH 1/2] mm/damon/core: fix damon_call() vs kdamond_fn() exit race

[SeongJae Park]

Forwarding Sashiko review for doing discussions via mails.

# review url: https://sashiko.dev/#/patchset/20260327233319.3528-2-sj@xxxxxxxxxx
# start of sashiko.dev inline review
commit 9cf54c95f0c4bda07c5dbaf4019d0d731f6c58fd
Author: SeongJae Park <sj@xxxxxxxxxx>

mm/damon/core: fix damon_call() vs kdamond_fn() exit race

This commit introduces a new call_controls_obsolete flag to prevent
damon_call() from adding requests to a terminating kdamond context.
It removes the after-registration DAMON context termination check.

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

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index db6c67e52d2b..9bcda2765ac9 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c

[ ... ]

> @@ -1629,10 +1604,12 @@ int damon_call(struct damon_ctx *ctx, struct damon_call_control *control)
>  	INIT_LIST_HEAD(&control->list);
>  
>  	mutex_lock(&ctx->call_controls_lock);
> +	if (ctx->call_controls_obsolete) {
> +		mutex_unlock(&ctx->call_controls_lock);
> +		return -ECANCELED;
> +	}
>  	list_add_tail(&control->list, &ctx->call_controls);
>  	mutex_unlock(&ctx->call_controls_lock);
> -	if (!damon_is_running(ctx))
> -		return damon_call_handle_inactive_ctx(ctx, control);
>  	if (control->repeat)
>  		return 0;
>  	wait_for_completion(&control->completion);

Can this code trigger a use-after-free on control?

This appears to be a pre-existing issue that remains unfixed. If
kdamond_fn() is terminating, it executes kdamond_call(ctx, true). This
function removes the request, sets it as canceled, and calls kfree(control)
if control->dealloc_on_cancel is true.

Since ctx->call_controls_lock is dropped right before the control->repeat
check:

CPU1 (kdamond_fn)
kdamond_call(ctx, true)
    list_del(&control->list);
    kfree(control);

CPU2 (damon_call)
    mutex_unlock(&ctx->call_controls_lock);
    if (control->repeat)

Could kdamond_call() free control before damon_call() evaluates
control->repeat?

Furthermore, if memory poisoning causes the freed memory to evaluate
control->repeat as false, would this proceed to call wait_for_completion()
on the freed memory and cause wait queue corruption?


# end of sashiko.dev inline review
# review url: https://sashiko.dev/#/patchset/20260327233319.3528-2-sj@xxxxxxxxxx
#
# hkml [1] generated a draft of this mail.  It can be regenerated
# using below command:
#
#     hkml patch sashiko_dev --for_forwarding \
#             20260327233319.3528-2-sj@xxxxxxxxxx
#
# [1] https://github.com/sjp38/hackermail

Sent using hkml (https://github.com/sjp38/hackermail)