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

[SeongJae Park <sj@kernel.org>]

On Thu,  2 Apr 2026 06:39:51 -0700 SeongJae Park <sj@kernel.org> wrote:

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

Posted it: https://lore.kernel.org/20260402134418.74121-1-sj@kernel.org

[...]
> 
> 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.

Because the reference is still there, I think it cannot technically be called
"leaked".


Thanks,
SJ

[...]