All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "SJ Park" <sj@kernel.org>
Cc: damon@lists.linux.dev
Subject: Re: [RFC PATCH 6/8] Docs/mm/damon/design: update for hugepage_size probe filter
Date: Sun, 13 Sep 2026 17:24:53 +0000	[thread overview]
Message-ID: <20260913172453.9592D1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260913171133.102366-7-sj@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Newly added probe filters of type DAMON_FILTER_TYPE_HUGEPAGE_SIZE are left with uninitialized `range_min` and `range_max` values, and bypass bounds validation.
--

commit b9cb7bf28c7342005a919d584ad8cc1ce1cf9694
Author: SJ Park <sj@kernel.org>

Docs/mm/damon/design: update for hugepage_size probe filter

Update DAMON design document for the newly added hugepage_size data
attribute probe filter type.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 0c98f7e267d07..a3febdc355c1e 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -1807,23 +1807,33 @@ static void damon_commit_filter(struct damon_filter *dst,
>  	case DAMON_FILTER_TYPE_MEMCG:
>  		dst->memcg_id = src->memcg_id;
>  		break;
> +	case DAMON_FILTER_TYPE_HUGEPAGE_SIZE:
> +		if (src->range_max < src->range_min)
> +			return -EINVAL;
> +		dst->range_min = src->range_min;
> +		dst->range_max = src->range_max;
> +		break;
>  	default:
>  		break;
>  	}
> +	return 0;
>  }
>  
>  static int damon_commit_filters(struct damon_probe *dst,
>  		struct damon_probe *src)
>  {
>  	struct damon_filter *dst_filter, *next, *src_filter, *new_filter;
> -	int i = 0, j = 0;
> +	int i = 0, j = 0, err;
>  
>  	damon_for_each_filter_safe(dst_filter, next, dst) {
>  		src_filter = damon_nth_filter(i++, src);
> -		if (src_filter)
> -			damon_commit_filter(dst_filter, src_filter);
> -		else
> +		if (src_filter) {
> +			err = damon_commit_filter(dst_filter, src_filter);
> +			if (err)
> +				return err;
> +		} else {
>  			damon_destroy_filter(dst_filter);
> +		}
>  	}
>  
>  	damon_for_each_filter_safe(src_filter, next, src) {

[ ... ]

> 		new_filter = damon_new_filter(src_filter->type,
> 				src_filter->matching, src_filter->allow);
> 		if (!new_filter)
> 			return -ENOMEM;
> 		switch (src_filter->type) {
> 		case DAMON_FILTER_TYPE_MEMCG:
> 			new_filter->memcg_id = src_filter->memcg_id;
> 			break;
> 		default:
> 			break;
> 		}
		^^^^

[Severity: High]
Does this code miss copying range_min and range_max when a HUGEPAGE_SIZE filter
is dynamically appended?

Since damon_new_filter() allocates new_filter without zeroing it, range_min and
range_max are left uninitialized for newly appended HUGEPAGE_SIZE filters.

Furthermore, because damon_commit_filter() isn't called here, the bounds
validation (src->range_max < src->range_min) added above is completely
bypassed. This leads to erratic memory filtering behavior since DAMON might
skip or apply actions based on memory garbage.

Should case DAMON_FILTER_TYPE_HUGEPAGE_SIZE be added to this switch block, or
perhaps the code could be refactored to reuse damon_commit_filter() here?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260913171133.102366-1-sj@kernel.org?part=6

  reply	other threads:[~2026-09-13 17:24 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-13 17:11 [RFC PATCH 0/8] mm/damon: introduce hugepage_size probe filter SJ Park
2026-09-13 17:11 ` [RFC PATCH 1/8] mm/damon/api: introduce DAMON_FILTER_TYPE_HUGEPAGE_SIZE SJ Park
2026-09-13 17:22   ` sashiko-bot
2026-09-13 17:31     ` SJ Park
2026-09-13 17:40       ` SJ Park
2026-09-13 17:11 ` [RFC PATCH 2/8] mm/damon/core: commit hugepage_size type damon filter SJ Park
2026-09-13 17:24   ` sashiko-bot
2026-09-13 17:33     ` SJ Park
2026-09-13 17:41       ` SJ Park
2026-09-13 17:11 ` [RFC PATCH 3/8] mm/damon/ops-common: support hugepage_size damon filter matching SJ Park
2026-09-13 17:24   ` sashiko-bot
2026-09-13 17:35     ` SJ Park
2026-09-13 17:41       ` SJ Park
2026-09-13 17:11 ` [RFC PATCH 4/8] mm/damon/sysfs: add min,max files under probe filter directory SJ Park
2026-09-13 17:16   ` sashiko-bot
2026-09-13 17:11 ` [RFC PATCH 5/8] mm/damon/sysfs: support hugepage_size probe filter SJ Park
2026-09-13 17:30   ` sashiko-bot
2026-09-13 17:38     ` SJ Park
2026-09-13 17:11 ` [RFC PATCH 6/8] Docs/mm/damon/design: update for " SJ Park
2026-09-13 17:24   ` sashiko-bot [this message]
2026-09-13 17:42     ` SJ Park
2026-09-13 17:11 ` [RFC PATCH 7/8] Docs/admin-guide/mm/damon/usage: update for hugepage_size SJ Park
2026-09-13 17:13   ` sashiko-bot
2026-09-13 17:11 ` [RFC PATCH 8/8] Docs/ABI/damon: update for hugepage_size probe filter SJ Park
2026-09-13 17:13   ` sashiko-bot

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=20260913172453.9592D1F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=damon@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sj@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.