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

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 t=
o `mm/damon/lru_sort.c`. This leaves `damon_lru_sort` vulnerable to the exa=
ct same bug.
--

--- Patch [1]: [RFC PATCH 1/2] mm/damon/reclaim: skip damon_call() if ctx h=
as not started ---
commit 86e90c966d8636445486cfde6487a797b433cb75
Author: SJ Park <[email protected]>

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 ord=
er
to safely skip damon_call().

Cc: <[email protected]> # 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 c=
har *val,
>  	if (!commit_inputs_request)
>  		return 0;
> =20
> -	/*
> -	 * 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;
> =20
>  	err =3D 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 =3D 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?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260802185430.9940=
[email protected]?part=3D1