Re: [PATCH v3 1/2] mm/damon/lru_sort: validate min_region_size to be power of 2

[Liew Rui Yan <aethernet65535@gmail.com>]

On Sat,  4 Apr 2026 13:30:43 -0700 SeongJae Park <sj@kernel.org> wrote:

> On Sat,  4 Apr 2026 17:11:22 +0800 Liew Rui Yan <aethernet65535@gmail.com> wrote:
> 
> > [...]
> > I think this deserves Cc stable@ because:
> > - The issue can be triggered by accidental user misconfiguration
> > - It causes kdamond termination and hard to recover/restart. Once
> >   triggered, kdamond remains in an unusable state, and I have not found
> >   a way to recover/restart it through the sysfs interface without a
> >   system reboot.
> > - The fix is small and low-risk
> > - It improves user experience on stable kernels
> 
> Thank you for elaborating this.  I now think this deserves Cc-ing stable@.

Thank you for agreeing to Cc stable@.

> Let's make sure the user impact is clearly documented on the commit message.
> Also, the code change itself and the current commit message is not clearly
> explaining how the real problem (DAMON cannot be restarted) can happen.  Please
> add the description in the next revision.

I will add an explanation of why DAMON cannot be restarted in the next
revision.

> [...]
> 
> > 
> > > For stable@ Cc-ing patches, more clearly describing the user impact would be
> > > nice, and helpful for judging if it deserves that.  Could you please elaborate?
> > 
> > I will add a "User Impact" section in v4's commit message:
> 
> Yes, please add this kind of message that make clear what is the user impact.
> 
> > 
> >     User Impact
> >     ===========
> >     Currently, if a user commit an invalid 'addr_unit', kdamond may
> >     terminate abruptly. Once terminated, it cannot be easily restarted
> >     via sysfs, pontentially requiring a system reboot to restore DAMON
> >     functionality. This patch prevent such termination by validating
> >     parameters (addr_unit and min_region_sz) early.
> 
> You mentioned it cannot be restarted above.  The above message sounds like
> there is a way to restart it via sysfs, though it is not easy.  Please make it
> clear and consistent.  As I also requested above, please add the internal
> mechanism of how that makes restart unable.  This itself doesn't explain it.

Thank you for your correction. I will make the description clear and
consistent, and also explain the internal mechanism 
(the 'maybe_corrupted' flag and why writing to 'enabled' cannot recover
it).

Note: 
Please excuse my slower responses in the coming weeks, as I have
upcoming exams. I will be most active and able to follow up during
weekend (Friday/Saturday).

Best regards,
Rui Yan