Re: [PATCH 2/4] mm/damon/core: set ctx->call_controls_obsolete in damon_new_ctx()

[SJ Park <sj@kernel.org>]

On Thu, 03 Sep 2026 01:16:20 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] The patch correctly fixes an indefinite wait vulnerability in damon_call() by initializing ctx->call_controls_obsolete to true, but fails to initialize the identical ctx->walk_control_obsolete flag. This leaves damos_walk() vulnerable to the exact same indefinite hang if called on an unstarted context.
> --
> 
> commit 55412502962e64df1de83b2c9805595450e93fc7
> Author: SJ Park <sj@kernel.org>
> 
> mm/damon/core: set ctx->call_controls_obsolete in damon_new_ctx()
> 
> This patch sets ctx->call_controls_obsolete to true in damon_new_ctx() to
> prevent indefinite hangs when damon_call() is used on an unstarted context.
> 
> Link: https://lore.kernel.org/20260803134646.16640-1-sj@kernel.org
> 
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > index f1f007d8dd1d9..610556abb129e 100644
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> > @@ -933,6 +933,7 @@ struct damon_ctx *damon_new_ctx(void)
> >  	INIT_LIST_HEAD(&ctx->adaptive_targets);
> >  	INIT_LIST_HEAD(&ctx->schemes);
> >  
> > +	ctx->call_controls_obsolete = true;
> 
> [Severity: High]
> This is a pre-existing issue, but does the same fix need to be applied to
> ctx->walk_control_obsolete?
> 
> Because walk_control_obsolete is zero-initialized (false) by kzalloc_obj(),
> calling damos_walk() on an unstarted context will bypass the obsolete check:
> 
> mm/damon/core.c:damos_walk() {
> 	if (ctx->walk_control_obsolete) {
> 		mutex_unlock(&ctx->walk_control_lock);
> 		return -ECANCELED;
> 	}
> 	...
> 	wait_for_completion(&control->completion);
> }
> 
> This could lead to an indefinite hang in wait_for_completion(), since the
> DAMON worker thread is not running to signal the completion. Should
> ctx->walk_control_obsolete also be initialized to true here?

The issue in damon_call() could happen because it has repeat mode.
damos_walk() doesn't have the repeat mode, so I don't think same issue exists
here.  I will consider doing so in future, for consistency.  But not something
need to be done now.

> 
> >  	prandom_seed_state(&ctx->rnd_state, get_random_u64());
> >  
> >  	return ctx;
> 
> [ ... ]
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260903010334.93622-1-sj@kernel.org?part=2


Thanks,
SJ