[RFC PATCH 0/8] mm/damon: introduce hugepage_size probe filter

[RFC PATCH 0/8] mm/damon: introduce hugepage_size probe filter

[SJ Park]

Knowing whether a given memory is backed by a hugepage of specific size
is useful for efficient utilization of hugepages.  For easy monitoring
of the information, introduce a new data attribute probe filter type,
hugepage_size.  It works similar to the DAMOS filter of the same name.
It works for memory that is backed by a hugepage of a given size range.

Patch 1 introduces the new probe filter type to DAMON API and extends
related data structures.  Patch 2 updates probe filter commit logic to
handle the size range.  Patch 3 Updates the filtering logic to support
the new type.  Patch 4 adds new DAMON sysfs files for the size range.
Patch 5 updates DAMON sysfs interface to fully support the new filter
type.  Patches 6-8 updates design, usage and ABI documents for the new
feature.

Test
====

Set THP always and start a test workload using masim [1].

    $ echo always | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
    $ ./masim.py run --config_file ./configs/stairs-500mb.cfg --repeat 10

Using the DAMON user-space tool, damo [2], start DAMON with two probes.
The primary probe monitors access.  The secondary probe monitors 2 MiB
sized hugepages.  The region adjustment weight is given to only the
primary probe.  That is, this setup is for showing access temperature
and additionally how many 2 MiB hugepages are being used for the region
of the access temperature.

    $ sudo ./damo start $(pidof masim) \
            --probe_prep set_pgidle --probe_filter allow pgidle_unset \
            --probe_filter allow hugepage_size 2M 2M --probe_weight 1 0 \
            --nr_probe_preps 1 0 --nr_probe_filters 1 1 --nr_probes 2

Show the monitoring results.

    $ sudo ./damo report attrs
    heatmap: 000004[...]666666668988888888888844444430000000000000000000000000000000000000000000014[...]8
    # min/max temperatures: -470,000,000, 10,000,500, column size: 64.119 MiB
    probes
    - prep: set_pgidle, filter: allow pgidle_unset (weight: 1)
    - allow hugepage_size [2.000 MiB, 2.000 MiB] (weight: 0)
    intervals: sample 5 ms aggr 100 ms (max probe hits 20)
    #   size         address       age           probe_hits
    0   354.039 MiB  85.833 TiB    4.700 s       0 0
    1   1.843 GiB    127.724 TiB   4.700 s       0 6
    2   936.781 MiB  127.726 TiB   4.600 s       0 16
    [...]
    25  44.000 KiB   127.723 TiB   0 ns          15 20
    26  11.492 MiB   127.723 TiB   0 ns          16 20
    27  2.160 MiB    127.723 TiB   0 ns          19 20
    [...]
    47  376.000 KiB  127.723 TiB   300 ms        1 20
    48  48.000 KiB   127.723 TiB   400 ms        2 20
    49  812.000 KiB  127.723 TiB   500 ms        9 20
    memory bw estimate: 0 B per second
    total size: 5.009 GiB
    record DAMON intervals: sample 5 ms, aggr 100 ms

The first probe_hits count and the age show the access temperature of
each region.  The second probe_hits count shows the ratio of 2 MiB
hugepages in the region.

For example, region 2, which has 936 MiB size, is quite cold (not
accessed for 4.6 seconds) but uses 2 MiB THP for ~80% (16/20) of the
region.  Maybe not a very efficient use of THP.

On the other hand, region 49, which is 812 KiB size, is somewhat hot
(accessed about 9 times per 100 ms for the last 500 ms) and fully backed
by 2 MiB hugepage.  Maybe this is a good use of THP.

[1] https://github.com/sjp38/masim
[2] https://github.com/damonitor/damo

SJ Park (8):
  mm/damon/api: introduce DAMON_FILTER_TYPE_HUGEPAGE_SIZE
  mm/damon/core: commit hugepage_size type damon filter
  mm/damon/ops-common: support hugepage_size damon filter matching
  mm/damon/sysfs: add min,max files under probe filter directory
  mm/damon/sysfs: support hugepage_size probe filter
  Docs/mm/damon/design: update for hugepage_size probe filter
  Docs/admin-guide/mm/damon/usage: update for hugepage_size
  Docs/ABI/damon: update for hugepage_size probe filter

 .../ABI/testing/sysfs-kernel-mm-damon         | 14 +++++
 Documentation/admin-guide/mm/damon/usage.rst  |  4 +-
 Documentation/mm/damon/design.rst             |  2 +
 include/linux/damon.h                         |  8 +++
 mm/damon/core.c                               | 20 +++++--
 mm/damon/ops-common.c                         | 10 ++++
 mm/damon/sysfs.c                              | 55 +++++++++++++++++++
 7 files changed, 107 insertions(+), 6 deletions(-)


base-commit: 91c120b49e83b867e29684fd229c3e1f07190071
-- 
2.47.3

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

[SJ Park]

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.  Add two new fields in the damon_filter struct for
saving the size range.

Signed-off-by: SJ Park <sj@kernel.org>
---
 include/linux/damon.h | 8 ++++++++
 1 file changed, 8 insertions(+)

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
@@ -783,12 +783,14 @@ struct damon_prep {
  * @DAMON_FILTER_TYPE_MEMCG:		Specific memcg's pages.
  * @DAMON_FILTER_TYPE_PGIDLE_UNSET:	Pgidle is unset.
  * @DAMON_FILTER_TYPE_PGIDLE_SET:	Pgidle is set.
+ * @DAMON_FILTER_TYPE_HUGEPAGE_SIZE:	Page is part of a hugepage.
  */
 enum damon_filter_type {
 	DAMON_FILTER_TYPE_ANON,
 	DAMON_FILTER_TYPE_MEMCG,
 	DAMON_FILTER_TYPE_PGIDLE_UNSET,
 	DAMON_FILTER_TYPE_PGIDLE_SET,
+	DAMON_FILTER_TYPE_HUGEPAGE_SIZE,
 };
 
 /**
@@ -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;
+		};
 	};
 /* private: */
 	/* Siblings list. */
-- 
2.47.3

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

[sashiko-bot]

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

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

[SJ Park]

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

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

[SJ Park]

On Sun, 13 Sep 2026 10:31:42 -0700 SJ Park <sj@kernel.org> wrote:

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

I was wrong.  I will fix this in the next spin.

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


Thanks,
SJ

[RFC PATCH 2/8] mm/damon/core: commit hugepage_size type damon filter

[SJ Park]

Extend data attribute probe filters commit logic for the new
hugepage_size filter type.  Since it needs to carry the size range of
the hugepage, update the logic to update the size range fields of the
commit destination filter struct.  While doing that, validate the given
range and propagate an error if it is invalid.  Add the error handling
in the callers, too.

Signed-off-by: SJ Park <sj@kernel.org>
---
 mm/damon/core.c | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/mm/damon/core.c b/mm/damon/core.c
index 5212bfb8f85f2..e2b41a434cd2b 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -1818,7 +1818,7 @@ static int damon_commit_preps(struct damon_probe *dst, struct damon_probe *src)
 	return 0;
 }
 
-static void damon_commit_filter(struct damon_filter *dst,
+static int damon_commit_filter(struct damon_filter *dst,
 		struct damon_filter *src)
 {
 	dst->type = src->type;
@@ -1828,23 +1828,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) {
-- 
2.47.3

Re: [RFC PATCH 2/8] mm/damon/core: commit hugepage_size type damon filter

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing initialization and validation of `range_min` and `range_max` for newly appended `hugepage_size` filters leads to uninitialized memory usage.
--

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

mm/damon/core: commit hugepage_size type damon filter

Extend data attribute probe filters commit logic for the new
hugepage_size filter type.  Since it needs to carry the size range of
the hugepage, update the logic to update the size range fields of the
commit destination filter struct.

> 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)
>  {

[ ... ]

>  	damon_for_each_filter_safe(src_filter, next, src) {
>  		if (j++ < i)
>  			continue;
>  
>  		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;
>  		}
>  		damon_add_filter(dst, new_filter);

[Severity: High]
Does this code leave range_min and range_max uninitialized for newly
appended hugepage_size filters?

If a user writes a new hugepage_size filter to a running probe via sysfs,
it triggers the filter appending path here:
damon_commit_ctx() -> damon_commit_probes() -> damon_commit_filters()

When the new filter is appended, damon_new_filter() allocates memory with
kmalloc(), which does not zero-initialize the memory. The switch statement
then omits copying range_min and range_max for
DAMON_FILTER_TYPE_HUGEPAGE_SIZE, leaving them as uninitialized heap garbage.

This makes the hugepage_size filter unpredictable and could cause incorrect
memory pages to be filtered in or out. It also completely bypasses the
validation logic added for existing filters in damon_commit_filter().

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

Re: [RFC PATCH 2/8] mm/damon/core: commit hugepage_size type damon filter

[SJ Park]

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

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Missing initialization and validation of `range_min` and `range_max` for newly appended `hugepage_size` filters leads to uninitialized memory usage.
> --
> 
> commit 2b0a5f30b2fda9db59b511fc77d64fcbd35378ca
> Author: SJ Park <sj@kernel.org>
> 
> mm/damon/core: commit hugepage_size type damon filter
> 
> Extend data attribute probe filters commit logic for the new
> hugepage_size filter type.  Since it needs to carry the size range of
> the hugepage, update the logic to update the size range fields of the
> commit destination filter struct.
> 
> > 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)
> >  {
> 
> [ ... ]
> 
> >  	damon_for_each_filter_safe(src_filter, next, src) {
> >  		if (j++ < i)
> >  			continue;
> >  
> >  		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;
> >  		}
> >  		damon_add_filter(dst, new_filter);
> 
> [Severity: High]
> Does this code leave range_min and range_max uninitialized for newly
> appended hugepage_size filters?
> 
> If a user writes a new hugepage_size filter to a running probe via sysfs,
> it triggers the filter appending path here:
> damon_commit_ctx() -> damon_commit_probes() -> damon_commit_filters()
> 
> When the new filter is appended, damon_new_filter() allocates memory with
> kmalloc(), which does not zero-initialize the memory. The switch statement
> then omits copying range_min and range_max for
> DAMON_FILTER_TYPE_HUGEPAGE_SIZE, leaving them as uninitialized heap garbage.
> 
> This makes the hugepage_size filter unpredictable and could cause incorrect
> memory pages to be filtered in or out. It also completely bypasses the
> validation logic added for existing filters in damon_commit_filter().

DAMON sysfs is not allowing hugepage_size filter at the moment, so this issue
cannot happen.  A later patch of this series will add the support with correct
range setup.

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


Thanks,
SJ

Re: [RFC PATCH 2/8] mm/damon/core: commit hugepage_size type damon filter

[SJ Park]

On Sun, 13 Sep 2026 10:33:22 -0700 SJ Park <sj@kernel.org> wrote:

> On Sun, 13 Sep 2026 17:24:21 +0000 sashiko-bot@kernel.org wrote:
> 
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > - [High] Missing initialization and validation of `range_min` and `range_max` for newly appended `hugepage_size` filters leads to uninitialized memory usage.
> > --
> > 
> > commit 2b0a5f30b2fda9db59b511fc77d64fcbd35378ca
> > Author: SJ Park <sj@kernel.org>
> > 
> > mm/damon/core: commit hugepage_size type damon filter
> > 
> > Extend data attribute probe filters commit logic for the new
> > hugepage_size filter type.  Since it needs to carry the size range of
> > the hugepage, update the logic to update the size range fields of the
> > commit destination filter struct.
> > 
> > > 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)
> > >  {
> > 
> > [ ... ]
> > 
> > >  	damon_for_each_filter_safe(src_filter, next, src) {
> > >  		if (j++ < i)
> > >  			continue;
> > >  
> > >  		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;
> > >  		}
> > >  		damon_add_filter(dst, new_filter);
> > 
> > [Severity: High]
> > Does this code leave range_min and range_max uninitialized for newly
> > appended hugepage_size filters?
> > 
> > If a user writes a new hugepage_size filter to a running probe via sysfs,
> > it triggers the filter appending path here:
> > damon_commit_ctx() -> damon_commit_probes() -> damon_commit_filters()
> > 
> > When the new filter is appended, damon_new_filter() allocates memory with
> > kmalloc(), which does not zero-initialize the memory. The switch statement
> > then omits copying range_min and range_max for
> > DAMON_FILTER_TYPE_HUGEPAGE_SIZE, leaving them as uninitialized heap garbage.
> > 
> > This makes the hugepage_size filter unpredictable and could cause incorrect
> > memory pages to be filtered in or out. It also completely bypasses the
> > validation logic added for existing filters in damon_commit_filter().
> 
> DAMON sysfs is not allowing hugepage_size filter at the moment, so this issue
> cannot happen.  A later patch of this series will add the support with correct
> range setup.

I was wrong.  I will fix this in the next spin.

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


Thanks,
SJ

[RFC PATCH 3/8] mm/damon/ops-common: support hugepage_size damon filter matching

[SJ Park]

Update ops-common data attribute filter matching logic to support
hugepage_size filter type.

Signed-off-by: SJ Park <sj@kernel.org>
---
 mm/damon/ops-common.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/mm/damon/ops-common.c b/mm/damon/ops-common.c
index c36cc39cd2c70..77366f42b3e5b 100644
--- a/mm/damon/ops-common.c
+++ b/mm/damon/ops-common.c
@@ -536,6 +536,7 @@ bool damon_ops_filter_match(struct damon_filter *filter, struct folio *folio)
 {
 	bool matched = false;
 	struct mem_cgroup *memcg;
+	size_t folio_sz;
 
 	switch (filter->type) {
 	case DAMON_FILTER_TYPE_ANON:
@@ -558,6 +559,15 @@ bool damon_ops_filter_match(struct damon_filter *filter, struct folio *folio)
 			matched = filter->memcg_id == mem_cgroup_id(memcg);
 		rcu_read_unlock();
 		break;
+	case DAMON_FILTER_TYPE_HUGEPAGE_SIZE:
+		if (!folio) {
+			matched = false;
+			break;
+		}
+		folio_sz = folio_size(folio);
+		matched = filter->range_min <= folio_sz &&
+			folio_sz <= filter->range_max;
+		break;
 	default:
 		break;
 	}
-- 
2.47.3

Re: [RFC PATCH 3/8] mm/damon/ops-common: support hugepage_size damon filter matching

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] damon_commit_filters() leaves range_min and range_max uninitialized for appended hugepage_size filters.
--

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

mm/damon/ops-common: support hugepage_size damon filter matching

Update ops-common data attribute filter matching logic to support
hugepage_size filter type.

> diff --git a/mm/damon/ops-common.c b/mm/damon/ops-common.c
> index c36cc39cd2c70..77366f42b3e5b 100644
> --- a/mm/damon/ops-common.c
> +++ b/mm/damon/ops-common.c

[ ... ]

> @@ -558,6 +559,15 @@ bool damon_ops_filter_match(struct damon_filter *filter, struct folio *folio)
>  			matched = filter->memcg_id == mem_cgroup_id(memcg);
>  		rcu_read_unlock();
>  		break;
> +	case DAMON_FILTER_TYPE_HUGEPAGE_SIZE:
> +		if (!folio) {
> +			matched = false;
> +			break;
> +		}
> +		folio_sz = folio_size(folio);
> +		matched = filter->range_min <= folio_sz &&
> +			folio_sz <= filter->range_max;
> +		break;

[Severity: High]
Does this new filter type need to be explicitly copied when a newly appended
filter is committed?

When userspace adds a new filter to an existing DAMON probe via sysfs,
damon_commit_filters() in mm/damon/core.c invokes damon_new_filter() which
allocates memory without zeroing it. The attributes are then copied in a
switch block:

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;
	}
	damon_add_filter(dst, new_filter);
	...
}

Because DAMON_FILTER_TYPE_HUGEPAGE_SIZE is missing from this switch block,
range_min and range_max will be left uninitialized for appended filters. This
could result in the filtering logic using garbage memory values.

Should DAMON_FILTER_TYPE_HUGEPAGE_SIZE be added to this switch statement
so the range boundaries are properly copied to the new filter?

>  	default:
>  		break;
>  	}

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

Re: [RFC PATCH 3/8] mm/damon/ops-common: support hugepage_size damon filter matching

[SJ Park]

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

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] damon_commit_filters() leaves range_min and range_max uninitialized for appended hugepage_size filters.
> --
> 
> commit 377608c283881250a794879309e80b931825b0d3
> Author: SJ Park <sj@kernel.org>
> 
> mm/damon/ops-common: support hugepage_size damon filter matching
> 
> Update ops-common data attribute filter matching logic to support
> hugepage_size filter type.
> 
> > diff --git a/mm/damon/ops-common.c b/mm/damon/ops-common.c
> > index c36cc39cd2c70..77366f42b3e5b 100644
> > --- a/mm/damon/ops-common.c
> > +++ b/mm/damon/ops-common.c
> 
> [ ... ]
> 
> > @@ -558,6 +559,15 @@ bool damon_ops_filter_match(struct damon_filter *filter, struct folio *folio)
> >  			matched = filter->memcg_id == mem_cgroup_id(memcg);
> >  		rcu_read_unlock();
> >  		break;
> > +	case DAMON_FILTER_TYPE_HUGEPAGE_SIZE:
> > +		if (!folio) {
> > +			matched = false;
> > +			break;
> > +		}
> > +		folio_sz = folio_size(folio);
> > +		matched = filter->range_min <= folio_sz &&
> > +			folio_sz <= filter->range_max;
> > +		break;
> 
> [Severity: High]
> Does this new filter type need to be explicitly copied when a newly appended
> filter is committed?
> 
> When userspace adds a new filter to an existing DAMON probe via sysfs,
> damon_commit_filters() in mm/damon/core.c invokes damon_new_filter() which
> allocates memory without zeroing it. The attributes are then copied in a
> switch block:
> 
> 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;
> 	}
> 	damon_add_filter(dst, new_filter);
> 	...
> }
> 
> Because DAMON_FILTER_TYPE_HUGEPAGE_SIZE is missing from this switch block,
> range_min and range_max will be left uninitialized for appended filters. This
> could result in the filtering logic using garbage memory values.
> 
> Should DAMON_FILTER_TYPE_HUGEPAGE_SIZE be added to this switch statement
> so the range boundaries are properly copied to the new filter?

No issue.  DAMON sysfs is not allowing hugepage_size probe filter at this
moment.  Later, it will add the support with proper range setup.

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


Thanks,
SJ

Re: [RFC PATCH 3/8] mm/damon/ops-common: support hugepage_size damon filter matching

[SJ Park]

On Sun, 13 Sep 2026 10:35:09 -0700 SJ Park <sj@kernel.org> wrote:

> On Sun, 13 Sep 2026 17:24:42 +0000 sashiko-bot@kernel.org wrote:
> 
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > - [High] damon_commit_filters() leaves range_min and range_max uninitialized for appended hugepage_size filters.
> > --
> > 
> > commit 377608c283881250a794879309e80b931825b0d3
> > Author: SJ Park <sj@kernel.org>
> > 
> > mm/damon/ops-common: support hugepage_size damon filter matching
> > 
> > Update ops-common data attribute filter matching logic to support
> > hugepage_size filter type.
> > 
> > > diff --git a/mm/damon/ops-common.c b/mm/damon/ops-common.c
> > > index c36cc39cd2c70..77366f42b3e5b 100644
> > > --- a/mm/damon/ops-common.c
> > > +++ b/mm/damon/ops-common.c
> > 
> > [ ... ]
> > 
> > > @@ -558,6 +559,15 @@ bool damon_ops_filter_match(struct damon_filter *filter, struct folio *folio)
> > >  			matched = filter->memcg_id == mem_cgroup_id(memcg);
> > >  		rcu_read_unlock();
> > >  		break;
> > > +	case DAMON_FILTER_TYPE_HUGEPAGE_SIZE:
> > > +		if (!folio) {
> > > +			matched = false;
> > > +			break;
> > > +		}
> > > +		folio_sz = folio_size(folio);
> > > +		matched = filter->range_min <= folio_sz &&
> > > +			folio_sz <= filter->range_max;
> > > +		break;
> > 
> > [Severity: High]
> > Does this new filter type need to be explicitly copied when a newly appended
> > filter is committed?
> > 
> > When userspace adds a new filter to an existing DAMON probe via sysfs,
> > damon_commit_filters() in mm/damon/core.c invokes damon_new_filter() which
> > allocates memory without zeroing it. The attributes are then copied in a
> > switch block:
> > 
> > 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;
> > 	}
> > 	damon_add_filter(dst, new_filter);
> > 	...
> > }
> > 
> > Because DAMON_FILTER_TYPE_HUGEPAGE_SIZE is missing from this switch block,
> > range_min and range_max will be left uninitialized for appended filters. This
> > could result in the filtering logic using garbage memory values.
> > 
> > Should DAMON_FILTER_TYPE_HUGEPAGE_SIZE be added to this switch statement
> > so the range boundaries are properly copied to the new filter?
> 
> No issue.  DAMON sysfs is not allowing hugepage_size probe filter at this
> moment.  Later, it will add the support with proper range setup.

I was wrong.  I will fix this in the next spin.

> 
> > 
> > >  	default:
> > >  		break;
> > >  	}
> > 
> > -- 
> > Sashiko AI review · https://sashiko.dev/#/patchset/20260913171133.102366-1-sj@kernel.org?part=3
> 
> 
> Thanks,
> SJ
> 


Thanks,
SJ

[RFC PATCH 4/8] mm/damon/sysfs: add min,max files under probe filter directory

[SJ Park]

In future, DAMON sysfs interface will support data attribute probe
filter types that have range arguments like the newly added
hugepage_size type filter.  To prepare such supports, add two new DAMON
sysfs files, min and max, under the probe filter directory.

Signed-off-by: SJ Park <sj@kernel.org>
---
 mm/damon/sysfs.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/mm/damon/sysfs.c b/mm/damon/sysfs.c
index 51fa506c879b0..8e8d89b8ed981 100644
--- a/mm/damon/sysfs.c
+++ b/mm/damon/sysfs.c
@@ -975,6 +975,8 @@ struct damon_sysfs_filter {
 	bool matching;
 	bool allow;
 	char *path;
+	unsigned long range_min;
+	unsigned long range_max;
 };
 
 static struct damon_sysfs_filter *damon_sysfs_filter_alloc(void)
@@ -1127,6 +1129,44 @@ static ssize_t path_store(struct kobject *kobj,
 	return count;
 }
 
+static ssize_t min_show(struct kobject *kobj,
+		struct kobj_attribute *attr, char *buf)
+{
+	struct damon_sysfs_filter *filter = container_of(kobj,
+			struct damon_sysfs_filter, kobj);
+
+	return sysfs_emit(buf, "%lu\n", filter->range_min);
+}
+
+static ssize_t min_store(struct kobject *kobj,
+		struct kobj_attribute *attr, const char *buf, size_t count)
+{
+	struct damon_sysfs_filter *filter = container_of(kobj,
+			struct damon_sysfs_filter, kobj);
+	int err = kstrtoul(buf, 0, &filter->range_min);
+
+	return err ? err : count;
+}
+
+static ssize_t max_show(struct kobject *kobj,
+		struct kobj_attribute *attr, char *buf)
+{
+	struct damon_sysfs_filter *filter = container_of(kobj,
+			struct damon_sysfs_filter, kobj);
+
+	return sysfs_emit(buf, "%lu\n", filter->range_max);
+}
+
+static ssize_t max_store(struct kobject *kobj,
+		struct kobj_attribute *attr, const char *buf, size_t count)
+{
+	struct damon_sysfs_filter *filter = container_of(kobj,
+			struct damon_sysfs_filter, kobj);
+	int err = kstrtoul(buf, 0, &filter->range_max);
+
+	return err ? err : count;
+}
+
 static void damon_sysfs_filter_release(struct kobject *kobj)
 {
 	struct damon_sysfs_filter *filter = container_of(kobj,
@@ -1148,11 +1188,19 @@ static struct kobj_attribute damon_sysfs_filter_allow_attr =
 static struct kobj_attribute damon_sysfs_filter_path_attr =
 		__ATTR_RW_MODE(path, 0600);
 
+static struct kobj_attribute damon_sysfs_filter_min_attr =
+		__ATTR_RW_MODE(min, 0600);
+
+static struct kobj_attribute damon_sysfs_filter_max_attr =
+		__ATTR_RW_MODE(max, 0600);
+
 static struct attribute *damon_sysfs_filter_attrs[] = {
 	&damon_sysfs_filter_type_attr.attr,
 	&damon_sysfs_filter_matching_attr.attr,
 	&damon_sysfs_filter_allow_attr.attr,
 	&damon_sysfs_filter_path_attr.attr,
+	&damon_sysfs_filter_min_attr.attr,
+	&damon_sysfs_filter_max_attr.attr,
 	NULL,
 };
 ATTRIBUTE_GROUPS(damon_sysfs_filter);
-- 
2.47.3

Re: [RFC PATCH 4/8] mm/damon/sysfs: add min,max files under probe filter directory

[sashiko-bot]

> In future, DAMON sysfs interface will support data attribute probe
> filter types that have range arguments like the newly added
> hugepage_size type filter.  To prepare such supports, add two new DAMON
> sysfs files, min and max, under the probe filter directory.
> 
> Signed-off-by: SJ Park <sj@kernel.org>

Sashiko has reviewed this patch and found no issues. It looks great!

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

[RFC PATCH 5/8] mm/damon/sysfs: support hugepage_size probe filter

[SJ Park]

Extend DAMON sysfs interface to support hugepage_size probe filter.
Allows hugepage_size user string input to the filter type file.  Pass
the size range argument that users set via min/max files under the probe
filter directory to the DAMON core.

Signed-off-by: SJ Park <sj@kernel.org>
---
 mm/damon/sysfs.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/mm/damon/sysfs.c b/mm/damon/sysfs.c
index 8e8d89b8ed981..43519afb9eb7f 100644
--- a/mm/damon/sysfs.c
+++ b/mm/damon/sysfs.c
@@ -1007,6 +1007,10 @@ damon_sysfs_filter_type_names[] = {
 		.type = DAMON_FILTER_TYPE_PGIDLE_SET,
 		.name = "pgidle_set",
 	},
+	{
+		.type = DAMON_FILTER_TYPE_HUGEPAGE_SIZE,
+		.name = "hugepage_size",
+	},
 };
 
 static ssize_t type_show(struct kobject *kobj,
@@ -2273,6 +2277,9 @@ static int damon_sysfs_set_filters(struct damon_probe *probe,
 				damon_destroy_filter(filter);
 				return err;
 			}
+		} else if (filter->type == DAMON_FILTER_TYPE_HUGEPAGE_SIZE) {
+			filter->range_min = sys_filter->range_min;
+			filter->range_max = sys_filter->range_max;
 		}
 		damon_add_filter(probe, filter);
 	}
-- 
2.47.3

Re: [RFC PATCH 5/8] mm/damon/sysfs: support hugepage_size probe filter

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Medium] Missing bounds validation for hugepage_size filter in damon_sysfs_set_filters().

Pre-existing issues:
- [High] Newly created hugepage_size filters lack range bounds initialization in damon_commit_filters(), causing the DAMON core to evaluate folios against uninitialized kernel heap memory.
--

commit 42f3666a978b5b2934ebb23daaee8fd5163c7793
Author: SJ Park <sj@kernel.org>
Subject: mm/damon/sysfs: support hugepage_size probe filter

This commit extends the DAMON sysfs interface to support the hugepage_size
probe filter. It allows users to set hugepage_size via sysfs min/max files
and passes these arguments to the DAMON core.

> diff --git a/mm/damon/sysfs.c b/mm/damon/sysfs.c
> index 8e8d89b8ed981..43519afb9eb7f 100644
> --- a/mm/damon/sysfs.c
> +++ b/mm/damon/sysfs.c

[ ... ]

> @@ -2273,6 +2277,9 @@ static int damon_sysfs_set_filters(struct damon_probe *probe,
>  				damon_destroy_filter(filter);
>  				return err;
>  			}
> +		} else if (filter->type == DAMON_FILTER_TYPE_HUGEPAGE_SIZE) {
> +			filter->range_min = sys_filter->range_min;
> +			filter->range_max = sys_filter->range_max;

[Severity: Medium]
Are bounds checks needed here to ensure range_min is less than or equal to
range_max?

Because DAMON's initial startup via damon_start() bypasses the bounds check
in damon_commit_filter(), turning DAMON on with inverted bounds in sysfs
silently accepts the configuration. The filter then unconditionally fails to
match any folios, resulting in a silent functional failure instead of an
expected -EINVAL rejection.

[Severity: High]
This isn't a bug introduced by this patch, but I noticed that newly created
hugepage_size filters lack range bounds initialization in
damon_commit_filters().

If a user configures a new hugepage_size filter via sysfs on an already
running DAMON context and writes 'commit' to the state file, the newly
added filter is allocated without initializing the range:

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;
		}
...
}

Because damon_new_filter() allocates memory without zeroing, and the switch
statement explicitly omits DAMON_FILTER_TYPE_HUGEPAGE_SIZE, range_min and
range_max are populated with uninitialized kernel heap memory. Could this
cause the DAMON core to evaluate folios against erratic heap garbage?

> +		}
>  		damon_add_filter(probe, filter);
>  	}

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

Re: [RFC PATCH 5/8] mm/damon/sysfs: support hugepage_size probe filter

[SJ Park]

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

> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> 
> New issues:
> - [Medium] Missing bounds validation for hugepage_size filter in damon_sysfs_set_filters().
> 
> Pre-existing issues:
> - [High] Newly created hugepage_size filters lack range bounds initialization in damon_commit_filters(), causing the DAMON core to evaluate folios against uninitialized kernel heap memory.
> --
> 
> commit 42f3666a978b5b2934ebb23daaee8fd5163c7793
> Author: SJ Park <sj@kernel.org>
> Subject: mm/damon/sysfs: support hugepage_size probe filter
> 
> This commit extends the DAMON sysfs interface to support the hugepage_size
> probe filter. It allows users to set hugepage_size via sysfs min/max files
> and passes these arguments to the DAMON core.
> 
> > diff --git a/mm/damon/sysfs.c b/mm/damon/sysfs.c
> > index 8e8d89b8ed981..43519afb9eb7f 100644
> > --- a/mm/damon/sysfs.c
> > +++ b/mm/damon/sysfs.c
> 
> [ ... ]
> 
> > @@ -2273,6 +2277,9 @@ static int damon_sysfs_set_filters(struct damon_probe *probe,
> >  				damon_destroy_filter(filter);
> >  				return err;
> >  			}
> > +		} else if (filter->type = DAMON_FILTER_TYPE_HUGEPAGE_SIZE) {
> > +			filter->range_min = sys_filter->range_min;
> > +			filter->range_max = sys_filter->range_max;
> 
> [Severity: Medium]
> Are bounds checks needed here to ensure range_min is less than or equal to
> range_max?
> 
> Because DAMON's initial startup via damon_start() bypasses the bounds check
> in damon_commit_filter(), turning DAMON on with inverted bounds in sysfs
> silently accepts the configuration. The filter then unconditionally fails to
> match any folios, resulting in a silent functional failure instead of an
> expected -EINVAL rejection.

No.  damon_start() does test purpose commit, so the bound check is done.

> 
> [Severity: High]
> This isn't a bug introduced by this patch, but I noticed that newly created
> hugepage_size filters lack range bounds initialization in
> damon_commit_filters().
> 
> If a user configures a new hugepage_size filter via sysfs on an already
> running DAMON context and writes 'commit' to the state file, the newly
> added filter is allocated without initializing the range:
> 
> 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;
> 		}
> ...
> }
> 
> Because damon_new_filter() allocates memory without zeroing, and the switch
> statement explicitly omits DAMON_FILTER_TYPE_HUGEPAGE_SIZE, range_min and
> range_max are populated with uninitialized kernel heap memory. Could this
> cause the DAMON core to evaluate folios against erratic heap garbage?

Good catch.  I will fix in the next spin.

> 
> > +		}
> >  		damon_add_filter(probe, filter);
> >  	}
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260913171133.102366-1-sj@kernel.org?part=5
> 


Thanks,
SJ

[RFC PATCH 6/8] Docs/mm/damon/design: update for hugepage_size probe filter

[SJ Park]

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

Signed-off-by: SJ Park <sj@kernel.org>
---
 Documentation/mm/damon/design.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
index 707170bcd1b33..0a86792f90a18 100644
--- a/Documentation/mm/damon/design.rst
+++ b/Documentation/mm/damon/design.rst
@@ -300,6 +300,8 @@ filter types.  Currently below filter types are supported.
 - ``pgidle_unset``: Matches if the page for the memory is marked as not
   access-idle.
 - ``pgidle_set``: Matches if the page for the memory is marked as access-idle.
+- ``hugepage_size``: Matches if the page for the memory is a part of a hugepage
+  of a given size range.
 
 If such probes are registered, DAMON executes the probes for each region's
 sampling memory when it does the access :ref:`sampling
-- 
2.47.3

Re: [RFC PATCH 6/8] Docs/mm/damon/design: update for hugepage_size probe filter

[sashiko-bot]

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

Re: [RFC PATCH 6/8] Docs/mm/damon/design: update for hugepage_size probe filter

[SJ Park]

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

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

Yes, I will fix this in the next spin.

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


Thanks,
SJ

[RFC PATCH 7/8] Docs/admin-guide/mm/damon/usage: update for hugepage_size

[SJ Park]

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

Signed-off-by: SJ Park <sj@kernel.org>
---
 Documentation/admin-guide/mm/damon/usage.rst | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
index d3e37400367bd..6b80bce5d678d 100644
--- a/Documentation/admin-guide/mm/damon/usage.rst
+++ b/Documentation/admin-guide/mm/damon/usage.rst
@@ -78,7 +78,7 @@ comma (",").
     │ │ │ │ │ │ │ │ │ 0/prep_action
     │ │ │ │ │ │ │ │ │ ...
     │ │ │ │ │ │ │ │ filters/nr_filters
-    │ │ │ │ │ │ │ │ │ 0/type,matching,allow,path
+    │ │ │ │ │ │ │ │ │ 0/type,matching,allow,path,min,max
     │ │ │ │ │ │ │ │ │ ...
     │ │ │ │ │ │ │ ...
     │ │ │ │ │ :ref:`targets <sysfs_targets>`/nr_targets
@@ -308,6 +308,8 @@ Writing a number (``N``) to the file creates the number of child directories
 named ``0`` to ``N-1``.  Each directory represents each filter and works in a
 way similar to that for :ref:`DAMOS filter <sysfs_filters>`.  When the filter
 ``type`` is ``memcg``, ``path`` file acts as ``memcg_path`` for :ref:`DAMOS
+filter <sysfs_filters>`.  When the filter ``type`` is ``hugepage_size``,
+``min`` and ``max`` files acts as files of the same names for :ref:`DAMOS
 filter <sysfs_filters>`.
 
 .. _sysfs_targets:
-- 
2.47.3

Re: [RFC PATCH 7/8] Docs/admin-guide/mm/damon/usage: update for hugepage_size

[sashiko-bot]

> Update DAMON usage document for the newly added hugepage_size data
> attribute filter type.
> 
> Signed-off-by: SJ Park <sj@kernel.org>

Sashiko has reviewed this patch and found no issues. It looks great!

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

[RFC PATCH 8/8] Docs/ABI/damon: update for hugepage_size probe filter

[SJ Park]

For the newly added hugepage_size data attribute probe filter, two new
sysfs files are added for the size range.  Update DAMON ABI document for
the new files.

Signed-off-by: SJ Park <sj@kernel.org>
---
 Documentation/ABI/testing/sysfs-kernel-mm-damon | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-damon b/Documentation/ABI/testing/sysfs-kernel-mm-damon
index ad21f58f3c912..55df688ea596f 100644
--- a/Documentation/ABI/testing/sysfs-kernel-mm-damon
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-damon
@@ -206,6 +206,20 @@ Description:	If 'memcg' is written to the 'type' file, writing to and
 		reading from this file sets and gets the path to the memory
 		cgroup of the interest.
 
+What:		/sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/probes/<P>/filters/<F>/min
+Date:		Sep 2026
+Contact:	SJ Park <sj@kernel.org>
+Description:	If 'hugepage_size' is written to the 'type' file, writing to and
+		reading from this file sets and gets the minimum size of the
+		huge page of the interest.
+
+What:		/sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/probes/<P>/filters/<F>/max
+Date:		Sep 2026
+Contact:	SJ Park <sj@kernel.org>
+Description:	If 'hugepage_size' is written to the 'type' file, writing to and
+		reading from this file sets and gets the maximum size of the
+		huge page of the interest.
+
 What:		/sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/probes/<P>/filters/<F>/matching
 Date:		May 2026
 Contact:	SJ Park <sj@kernel.org>
-- 
2.47.3

Re: [RFC PATCH 8/8] Docs/ABI/damon: update for hugepage_size probe filter

[sashiko-bot]

> For the newly added hugepage_size data attribute probe filter, two new
> sysfs files are added for the size range.  Update DAMON ABI document for
> the new files.
> 
> Signed-off-by: SJ Park <sj@kernel.org>

Sashiko has reviewed this patch and found no issues. It looks great!

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