Re: [PATCH] mm/damon/core: reject empty access pattern intervals on scheme commit

[Wang Xiaolei]

Hi SeongJae and Aveline

 Thank you both for the careful review.

I appreciate the clarification that DAMON simply executes what

 the user configured, and that this is more of an input validation

improvement than a bug fix. Perhaps I was too aggressive in framing

it as a bug.

thanks

xiaolei

在 2026/11/3 22:53, SJ Park 写道:
> On Tue,  3 Nov 2026 18:54:18 +0800 "Xiaolei Wang (Kaihong)" <xiaoleiwangxiaolei@xxxxxxxxx> wrote:
>
> > DAMOS schemes accept access pattern bounds with min > max (e.g.
> > min_sz_region > max_sz_region).  No input path validates the bounds:
> > damon_new_scheme() stores the pattern as is, and the sysfs ul_range
> > stores are plain kstrtoul().
> >
> > At runtime __damos_valid_target() evaluates "min <= x <= max" for each
> > of the three pattern dimensions.  A reversed interval is an empty set,
> > so every region fails the check and the scheme silently never matches
> > anything: nr_tried stays zero forever while the kdamond keeps running
> > normally.
> >
> > With such a reversed interval, damo starts normally (rc=0, kdamond
> > state=on), but nr_tried and nr_applied stay zero forever and the target
> > RSS does not drop.
> >
> > The same holds for the watermarks thresholds, which must be monotonic
> > (low <= mid <= high).
> >
> > Validate the access pattern and watermarks at the beginning of
> > damos_commit(), through which both new schemes (damo start) and online
> > updates (damo tune) pass.
> The documentation is not explicitly mentioning about the inputs (min > max and
> non-monotonic watermarks).  But I was thinking it is not really difficult to
> infer this behavior based on the existing document.
>
> If my understanding of the documentation is not wrong, I find no problem at
> accepting the inputs and just behave as documented.  It might look silly, but
> who knows the users have a creative reason to do that?  As long as it is not
> causing a harm, just supporting it is better for both users and code
> maintainability, in my humble opinion.
>
> Pleae let me know if I am missing something.
>
>
> Thanks,
> SJ
>
> [...]