Re: [RFC PATCH 1/8] mm/damon/api: introduce DAMON_FILTER_TYPE_HUGEPAGE_SIZE

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Uninitialized memory usage for new `DAMON_FILTER_TYPE_HUGEPAGE_SIZE` filters.
--

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

mm/damon/api: introduce DAMON_FILTER_TYPE_HUGEPAGE_SIZE

Introduce a new data attribute probe filter type, hugepage_size. It will
work for memory that is backed by a hugepage of a given size range. Add a
new damon_filter_type enum DAMON_FILTER_TYPE_HUGEPAGE_SIZE to identify the
type.

> diff --git a/include/linux/damon.h b/include/linux/damon.h
> index 4be7d1df8e71f..bbb190b474015 100644
> --- a/include/linux/damon.h
> +++ b/include/linux/damon.h

[ ... ]

> @@ -798,6 +800,8 @@ enum damon_filter_type {
>   * @matching:	Whether this filter is for the type-matching ones.
>   * @allow:	Whether the @type-@matching ones should pass this filter.
>   * @memcg_id:	Memcg id of the question if @type is DAMON_FILTER_MEMCG.
> + * @range_min:	Minimum value of range arguments.
> + * @range_max:	Maximum value of range arguments.
>   */
>  struct damon_filter {
>  	enum damon_filter_type type;
> @@ -805,6 +809,10 @@ struct damon_filter {
>  	bool allow;
>  	union {
>  		u64 memcg_id;
> +		struct {
> +			unsigned long range_min;
> +			unsigned long range_max;
> +		};

[Severity: High]
Will the range_min and range_max fields remain uninitialized when a filter
of type DAMON_FILTER_TYPE_HUGEPAGE_SIZE is committed?

Looking at damon_commit_filters() in mm/damon/core.c, new filters are allocated
but the switch statement doesn't have a case to copy the new size fields:

mm/damon/core.c:damon_commit_filters() {
	...
	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;
	}
	...
}

Since the switch falls through to default, range_min and range_max are not
copied from the source filter, leaving them as random heap garbage. Later,
when damon_ops_filter_match() evaluates the filter, it checks the page size
against these uninitialized bounds.

Also, the unit test for committing filters seems to omit checking this new
type as well, which is why it didn't catch the missing copy:

mm/damon/tests/core-kunit.h:damon_test_commit_filter_for() {
	...
	switch (src->type) {
	case DAMON_FILTER_TYPE_MEMCG:
		KUNIT_EXPECT_EQ(test, dst->memcg_id, src->memcg_id);
		break;
	default:
		break;
	}
	...
}

Should these switch statements be updated to explicitly handle
DAMON_FILTER_TYPE_HUGEPAGE_SIZE?

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