Re: (sashiko review) [RFC PATCH] mm/damon/stat: deallocate damon_call() failure leaking damon_ctx

SeongJae Park
2026-04-02T13:39:58Z

TL; DR: sashiko didn't find a real issue here. I will post non-RFC patch soon.

Forwarding Sashiko review in a usual reply format, with my inline comment for
doing discussions via mails.

> # review url: https://sashiko.dev/#/patchset/20260402045928.71170-1-sj@kernel.org
> # start of sashiko.dev inline review
> commit 8adb3c95d68d8448c8f57865d9874a5277cc1540
> Author: SeongJae Park <sj@kernel.org>
>
> mm/damon/stat: deallocate damon_call() failure leaking damon_ctx
>
> This commit attempts to fix a memory leak of the damon_ctx object when
> damon_call() fails, by deferring deallocation to a subsequent start call
> to avoid a use-after-free with the terminating kdamond thread.
>
> Link: https://lore.kernel.org/20260401012428.86694-1-sj@kernel.org
>
> > diff --git a/mm/damon/stat.c b/mm/damon/stat.c
> > --- a/mm/damon/stat.c
> > +++ b/mm/damon/stat.c
> > @@ -245,6 +245,12 @@ static int damon_stat_start(void)
> > {
> > int err;
> >
> > + if (damon_stat_context) {
> > + if (damon_is_running(damon_stat_context))
> > + return -EAGAIN;
>
> If the user retries while the background thread is still terminating, this
> will return -EAGAIN. Does this break standard sysfs boolean expectations,
> forcing userspace scripts to implement arbitrary retry loops?

I don't think that's a problem.

>
> Also, if the user never writes "Y" to the "enabled" sysfs parameter again,
> does the memory remain permanently leaked?

In a sense someone can argue so. Someone else may also argue it as "cached".
Anyway the total amount of "leaked" or "cached" memory is just single damon_ctx
object. No problem in my opinion.

>
> Could this be fixed synchronously by calling damon_stat_stop() in the error
> path of damon_stat_start() instead? Since damon_stop() safely blocks via
> kthread_stop_put() until the thread has fully exited, it seems it would
> allow immediate and safe deallocation without returning -EAGAIN.

damon_stop() was not designed for the purpose. Calling damon_stop() for
terminating kdamond also feels odd. For a hotfix, I think the current patch is
good.

>
> > + damon_destroy_ctx(damon_stat_context);
> > + }
> > +
> > damon_stat_context = damon_stat_build_ctx();
>
>
> # end of sashiko.dev inline review
> # review url: https://sashiko.dev/#/patchset/20260402045928.71170-1-sj@kernel.org

Thanks,
SJ …