Re: [RFC PATCH 1/2] mm/damon/reclaim: skip damon_call() if ctx has not started

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the patch fixes an indefinite hang in `mm/damon/reclaim.c` when writing to `commit_inputs` before the DAMON context starts, while failing to apply the identical fix to `mm/damon/lru_sort.c`. This leaves `damon_lru_sort` vulnerable to the exact same bug.
--

--- Patch [1]: [RFC PATCH 1/2] mm/damon/reclaim: skip damon_call() if ctx has not started ---
commit 86e90c966d8636445486cfde6487a797b433cb75
Author: SJ Park <sj@kernel.org>

mm/damon/reclaim: skip damon_call() if ctx has not started

This commit addresses an indefinite hang in DAMON reclaim when writing to
commit_inputs before the context has fully started. It introduces a tracking
flag to determine whether the DAMON context has successfully started in order
to safely skip damon_call().

Cc: <stable@vger.kernel.org> # 7.2.x

> diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
> index 09e941d75f67d..45d5557cc575a 100644
> --- a/mm/damon/reclaim.c
> +++ b/mm/damon/reclaim.c
[ ... ]
> @@ -291,11 +293,8 @@ static int damon_reclaim_commit_inputs_store(const char *val,
>  	if (!commit_inputs_request)
>  		return 0;
>  
> -	/*
> -	 * Skip damon_call() if ctx is not initialized to avoid
> -	 * NULL pointer dereference.
> -	 */
> -	if (!ctx)
> +	/* Skip damon_call() if ctx has not successfully started. */
> +	if (!damon_reclaim_damon_has_started)
>  		return -EINVAL;
>  
>  	err = damon_call(ctx, &control);

[Severity: High]
This isn't a bug introduced by this patch, but does the same vulnerability
exist in mm/damon/lru_sort.c?

It looks like damon_lru_sort_commit_inputs_store() uses the exact same
logic that was fixed here in reclaim.c:

mm/damon/lru_sort.c:damon_lru_sort_commit_inputs_store() {
    ...
    /*
     * Skip damon_call() if ctx is not initialized to avoid
     * NULL pointer dereference.
     */
    if (!ctx)
        return -EINVAL;

    err = damon_call(ctx, &control);
    ...
}

If a user writes to commit_inputs for damon_lru_sort before the thread has
started, could damon_call() blindly invoke wait_for_completion() and hang
indefinitely without a running thread to signal it?

Should a similar fix be applied to mm/damon/lru_sort.c to prevent a task
from hanging in an uninterruptible sleep state?

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