Re: (sashiko review) [RFC v5] mm/damon: add synchronous commit for commit_inputs

[SeongJae Park <sj@kernel.org>]

On Thu, 26 Mar 2026 14:15:54 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:

> Hi SeongJae,
> 
> On Wed, 25 Mar 2026 07:19:56 -0700, SeongJae Park <sj@kernel.org> wrote:
> 
> > Hi Liew,
> > 
> > On Wed, 25 Mar 2026 15:17:09 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:
[...]
> > > I will add a patch in v6 to validate 'addr_unit' in addr_unit_store() to
> > > reject non-power-of-2 inputs immediately.
> > 
> > That's because kdamond_fn() has recently changed to exit the loop if
> > damon_commit_ctx() fails in the loop for any reason.  Refer to commit
> > 26f775a054c3 ("mm/damon/core: avoid use of half-online-committed context") for
> > more details.
> > 
> > Adding the validation in addr_unit_store() would work, but it could be a kind
> > of whack-a-mole game.  I'd prefer doing the validation of all inputs in one
> > place, just before the last damon_commit_ctx() call.  DAMON_SYSFS is doing so,
> > by making a test context and try committing user input to the test context
> > before doing that to the running context.  How about doing so here, too?
> 
> Thank you for the suggestion. I have now added the check
> '!src->addr_unit || ! is_power_of_2(src->addr_unit)' to
> damon_commit_ctx().

No, what I'm suggesting is not adding more checks, but reusing the existing
checks in damon_commit_ctx().

And, now I think bit differently.  Given the purpose of this patch is making
commit_inputs synchronous, I think making more complete validation check is
somewhat that can be done separately.  So my suggestion now is just keeping
this part just as is.

[...]
> > So the issue already exists.  But let's ensure the fix is merged before this
> > patch, since this patch adds another exploitable path that can consequence in
> > whole param_lock deadlock.
> 
> Should I wait for your fix to be merged into damon/next before I post
> the next version?

As long as you agree about the mainline merge order, I think you don't need to
wait for my fix.  Please feel free to post next version.

FYI, the latest version of my fix is available [1] on the mailing list.

[1] https://lore.kernel.org/20260327004952.58266-1-sj@kernel.org


Thanks,
SJ

[...]