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

[Wang Xiaolei <xiaoleiwangxiaolei@gmail.com>]

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@gmail.com> 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
>
> [...]