public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: Josh Law <objecting@objecting.org>
Cc: SeongJae Park <sj@kernel.org>,
	akpm@linux-foundation.org, damon@lists.linux.dev,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] mm/damon/reclaim: fix min_age_region truncation from unsigned long to unsigned int
Date: Thu, 19 Mar 2026 19:48:13 -0700	[thread overview]
Message-ID: <20260320024814.1922-1-sj@kernel.org> (raw)
In-Reply-To: <20260319161620.189392-3-objecting@objecting.org>

On Thu, 19 Mar 2026 16:16:20 +0000 Josh Law <objecting@objecting.org> wrote:

> min_age / aggr_interval can exceed UINT_MAX with extreme but valid
> module parameter values, silently truncating min_age_region and
> lowering the cold-page age threshold below what the user intended.
> Clamp the result to UINT_MAX to match the field's type.

I believe the issue is not making real issue in real life.  But fixing this
makes the code cleaner to read, so I think this is better to have.  Thank you!

> 
> Signed-off-by: Josh Law <objecting@objecting.org>

Reviewed-by: SeongJae Park <sj@kernel.org>

> ---
>  mm/damon/reclaim.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
> index 9b55df304e51..303c64a56073 100644
> --- a/mm/damon/reclaim.c
> +++ b/mm/damon/reclaim.c
> @@ -170,8 +170,8 @@ static struct damos *damon_reclaim_new_scheme(void)
>  		.min_nr_accesses = 0,
>  		.max_nr_accesses = 0,
>  		/* for min_age or more micro-seconds */
> -		.min_age_region = min_age /
> -			damon_reclaim_mon_attrs.aggr_interval,
> +		.min_age_region = min_t(unsigned long, min_age /
> +			damon_reclaim_mon_attrs.aggr_interval, UINT_MAX),
>  		.max_age_region = UINT_MAX,
>  	};

Sashiko comment.
# review url: https://sashiko.dev/#/patchset/20260319161620.189392-3-objecting@objecting.org

: Could direct access to damon_reclaim_mon_attrs.aggr_interval result in a
: division by zero? If a user writes 0 to the module parameter concurrently via
: sysfs between the validation step and this division, it appears the interval
: could be zero here.

Makes sense, but orthogonal to this patch.  I will work on this.

: 
: Also, since both min_age_region and max_age_region are now clamped or set to
: UINT_MAX, the target matching condition becomes exactly UINT_MAX. In
: mm/damon/core.c (kdamond_merge_regions), a region's age increments on each
: interval via r->age++ without bounds checking.
: 
: Does this mean a region's age will hit UINT_MAX, match for a single interval,
: and then wrap around to 0, effectively defeating the "reclaim if older than
: X" logic?

Good point.  But such case may be too rare to consider...?  Anyway irrelevant
to this patch.  I will take more time to think about this.

: 
: Finally, should similar clamping be applied to other DAMON modules? For
: example, in mm/damon/lru_sort.c, cold_thres and hot_thres are computed from
: unsigned long parameters but typed as unsigned int. Similarly, in
: mm/damon/sysfs-schemes.c, damon_sysfs_mk_scheme assigns unsigned long
: boundaries to the damos_access_pattern fields, which could also result in
: silent truncation.

Yes, similar issue may exist in DAMON_LRU_SORT.  But definitely it is
orthogonal to this patch.  Also, as I mentioned above, I think this change is
good to have but not really fixing real critical issue.  If a nice person send
a patch for this, I'd appreciate.


Thanks,
SJ


      reply	other threads:[~2026-03-20  2:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-19 16:16 [PATCH 0/2] mm/damon/reclaim: fix addr_unit validation and age truncation Josh Law
2026-03-19 16:16 ` [PATCH 1/2] mm/damon/reclaim: reject non-power-of-2 addr_unit Josh Law
2026-03-20  2:29   ` SeongJae Park
2026-03-19 16:16 ` [PATCH 2/2] mm/damon/reclaim: fix min_age_region truncation from unsigned long to unsigned int Josh Law
2026-03-20  2:48   ` SeongJae Park [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260320024814.1922-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=damon@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=objecting@objecting.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox