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

[SJ Park <sj@kernel.org>]

On Sun, 13 Sep 2026 17:22:04 +0000 sashiko-bot@kernel.org wrote:

> 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?

Yes, and that is what the next patch of this series is doing.

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


Thanks,
SJ