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

[RFC PATCH v2 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 \
                --probe_prep set_pgidle --probe_filter allow pgidle_unset \
                --probe_weight 1 \
            --probe \
                --probe_filter allow hugepage_size 2M 2M

Show the monitoring results.

    $ sudo ./damo report attrs
    heatmap: 000000000003[...]666666666666666666666666666666666666666666666668888888888888988888888[...]8
    # min/max temperatures: -2,770,000,000, 68,474,934, column size: 69.784 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   250.805 MiB  86.185 TiB    27.700 s      0 0
    1   556.285 MiB  86.184 TiB    27.400 s      0 0
    2   1.629 GiB    127.488 TiB   8.500 s       0 4
    3   535.770 MiB  127.490 TiB   8.400 s       0 7
    4   1.066 GiB    127.490 TiB   8.200 s       0 6
    5   501.332 MiB  127.492 TiB   600 ms        0 12
    [...]
    50  146.133 MiB  127.492 TiB   200 ms        2 20
    51  16.000 KiB   127.492 TiB   200 ms        11 20
    52  144.000 KiB  127.492 TiB   200 ms        17 20
    53  48.000 KiB   127.492 TiB   200 ms        18 20
    54  1.930 MiB    127.492 TiB   200 ms        19 20
    [...]
    101 1.996 MiB    127.492 TiB   2.100 s       1 20
    102 1.992 MiB    127.492 TiB   2.100 s       20 20
    103 1.984 MiB    127.492 TiB   2.200 s       1 20
    104 2.000 MiB    127.492 TiB   2.300 s       20 20
    105 2.000 MiB    127.492 TiB   2.600 s       20 20
    memory bw estimate: 0 B per second
    total size: 5.452 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 region is sorted by access temperature, which is a
weighted sum of the first probe_hits count and the age.  That is,
regions at the beginning of the list are colder than those at the end of
the list.  The second probe_hits count shows the ratio of 2 MiB
hugepages in the region.

For example, region 5, which has 501.332 MiB size, has not accessed for
the last 600 milliseconds and uses 2 MiB THP for ~60% (12/20) of the
region.

Region 105, which is 2 MiB size, has been accessed at least 20 times per
100 milliseconds for the last 2.6 seconds) and fully backed by 2 MiB
hugepage.

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

Changes from RFC
- RFC: https://lore.kernel.org/20260913171133.102366-1-sj@kernel.org
- Commit size range for newly added hugepage_size filter.
- Rebase to latest mm-new.

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                               | 26 +++++++--
 mm/damon/ops-common.c                         | 10 ++++
 mm/damon/sysfs.c                              | 55 +++++++++++++++++++
 7 files changed, 113 insertions(+), 6 deletions(-)


base-commit: 40d32defbd03e19f5767a2118f8d28cd0241dded
-- 
2.47.3

[RFC PATCH v2 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 v2 1/8] mm/damon/api: introduce DAMON_FILTER_TYPE_HUGEPAGE_SIZE

[sashiko-bot]

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

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

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

[RFC PATCH v2 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 | 26 +++++++++++++++++++++-----
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/mm/damon/core.c b/mm/damon/core.c
index 5212bfb8f85f2..4cd7eec7b8ec5 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) {
@@ -1859,6 +1869,12 @@ static int damon_commit_filters(struct damon_probe *dst,
 		case DAMON_FILTER_TYPE_MEMCG:
 			new_filter->memcg_id = src_filter->memcg_id;
 			break;
+		case DAMON_FILTER_TYPE_HUGEPAGE_SIZE:
+			if (src_filter->range_max < src_filter->range_min)
+				return -EINVAL;
+			new_filter->range_min = src_filter->range_min;
+			new_filter->range_max = src_filter->range_max;
+			break;
 		default:
 			break;
 		}
-- 
2.47.3

Re: [RFC PATCH v2 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:
- [Medium] Memory leak of newly allocated `damon_filter` on the error path in `damon_commit_filters()`.
--

commit 5bd56b851690ccc1ea59e5d967224bde8e275c2a
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. This updates the size range fields of the commit destination
filter struct and validates the given range.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 0c98f7e267d07..ecfe99450e5f0 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
[ ... ]
> @@ -1838,6 +1848,12 @@ static int damon_commit_filters(struct damon_probe *dst,
>  		case DAMON_FILTER_TYPE_MEMCG:
>  			new_filter->memcg_id = src_filter->memcg_id;
>  			break;
> +		case DAMON_FILTER_TYPE_HUGEPAGE_SIZE:
> +			if (src_filter->range_max < src_filter->range_min)
> +				return -EINVAL;

[Severity: Medium]
Does this error path leak the newly allocated new_filter?

It looks like damon_commit_filters() returns early here without adding
new_filter to the destination list or freeing it. Since this is reachable
via the sysfs interface when a user configures a filter with a minimum
larger than the maximum, can this cause a memory leak on invalid input?

> +			new_filter->range_min = src_filter->range_min;
> +			new_filter->range_max = src_filter->range_max;
> +			break;
>  		default:
>  			break;
>  		}

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

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

[SJ Park]

On Mon, 14 Sep 2026 14:52:16 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Memory leak of newly allocated `damon_filter` on the error path in `damon_commit_filters()`.
> --
> 
> commit 5bd56b851690ccc1ea59e5d967224bde8e275c2a
> 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. This updates the size range fields of the commit destination
> filter struct and validates the given range.
> 
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > index 0c98f7e267d07..ecfe99450e5f0 100644
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> [ ... ]
> > @@ -1838,6 +1848,12 @@ static int damon_commit_filters(struct damon_probe *dst,
> >  		case DAMON_FILTER_TYPE_MEMCG:
> >  			new_filter->memcg_id = src_filter->memcg_id;
> >  			break;
> > +		case DAMON_FILTER_TYPE_HUGEPAGE_SIZE:
> > +			if (src_filter->range_max < src_filter->range_min)
> > +				return -EINVAL;
> 
> [Severity: Medium]
> Does this error path leak the newly allocated new_filter?
> 
> It looks like damon_commit_filters() returns early here without adding
> new_filter to the destination list or freeing it. Since this is reachable
> via the sysfs interface when a user configures a filter with a minimum
> larger than the maximum, can this cause a memory leak on invalid input?

Good finding.  I will fix in the next revision.

> 
> > +			new_filter->range_min = src_filter->range_min;
> > +			new_filter->range_max = src_filter->range_max;
> > +			break;
> >  		default:
> >  			break;
> >  		}
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260914144448.93732-1-sj@kernel.org?part=2


Thanks,
SJ

[RFC PATCH v2 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 v2 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:
- [Medium] Memory leak of newly allocated filter when HUGEPAGE_SIZE range is invalid.
--

commit 5ea2818b5d3def212dc5a08d79877c1ebf66bd6e
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/core.c b/mm/damon/core.c
> index 0c98f7e267d07..ecfe99450e5f0 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
[ ... ]
> @@ -1838,6 +1848,12 @@ static int damon_commit_filters(struct damon_probe *dst,
>  		case DAMON_FILTER_TYPE_MEMCG:
>  			new_filter->memcg_id = src_filter->memcg_id;
>  			break;
> +		case DAMON_FILTER_TYPE_HUGEPAGE_SIZE:
> +			if (src_filter->range_max < src_filter->range_min)
> +				return -EINVAL;

[Severity: Medium]
Does this return path leak new_filter?

When src_filter->range_max < src_filter->range_min evaluates to true
in damon_commit_filters(), the function returns -EINVAL immediately.

Since new_filter was already allocated earlier in the loop:

        new_filter = damon_new_filter(src_filter->type,
                        src_filter->matching, src_filter->allow);
        if (!new_filter)
                return -ENOMEM;

and has not yet been added to the probe's filter list or freed before
this return, does this drop the only reference to it?

> +			new_filter->range_min = src_filter->range_min;
> +			new_filter->range_max = src_filter->range_max;
> +			break;
>  		default:
>  			break;
>  		}

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

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

[SJ Park]

On Mon, 14 Sep 2026 14:59:36 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Memory leak of newly allocated filter when HUGEPAGE_SIZE range is invalid.
> --
> 
> commit 5ea2818b5d3def212dc5a08d79877c1ebf66bd6e
> 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/core.c b/mm/damon/core.c
> > index 0c98f7e267d07..ecfe99450e5f0 100644
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> [ ... ]
> > @@ -1838,6 +1848,12 @@ static int damon_commit_filters(struct damon_probe *dst,
> >  		case DAMON_FILTER_TYPE_MEMCG:
> >  			new_filter->memcg_id = src_filter->memcg_id;
> >  			break;
> > +		case DAMON_FILTER_TYPE_HUGEPAGE_SIZE:
> > +			if (src_filter->range_max < src_filter->range_min)
> > +				return -EINVAL;
> 
> [Severity: Medium]
> Does this return path leak new_filter?
> 
> When src_filter->range_max < src_filter->range_min evaluates to true
> in damon_commit_filters(), the function returns -EINVAL immediately.
> 
> Since new_filter was already allocated earlier in the loop:
> 
>         new_filter = damon_new_filter(src_filter->type,
>                         src_filter->matching, src_filter->allow);
>         if (!new_filter)
>                 return -ENOMEM;
> 
> and has not yet been added to the probe's filter list or freed before
> this return, does this drop the only reference to it?

Will fix in the next spin.

> 
> > +			new_filter->range_min = src_filter->range_min;
> > +			new_filter->range_max = src_filter->range_max;
> > +			break;
> >  		default:
> >  			break;
> >  		}
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260914144448.93732-1-sj@kernel.org?part=3
> 


Thanks,
SJ

[RFC PATCH v2 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 v2 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/20260914144448.93732-1-sj@kernel.org?part=4

[RFC PATCH v2 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 v2 5/8] mm/damon/sysfs: support hugepage_size probe filter

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing range validation for hugepage_size filters in sysfs allows triggering a memory leak in the DAMON core.
--

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

mm/damon/sysfs: support hugepage_size probe filter

Extend DAMON sysfs interface to support hugepage_size probe filter. Allows
hugepage_size user string input to the filter type file and passes the size
range argument via min/max files 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;
>  		}
>  		damon_add_filter(probe, filter);
>  	}

[Severity: High]
Does this code need validation to ensure sys_filter->range_min <=
sys_filter->range_max before passing the values to the DAMON core?

If a local user configures a filter with a minimum value greater than the
maximum value, this unvalidated input will reach damon_commit_filters() in
mm/damon/core.c.

In damon_commit_filters(), the core detects the invalid range but returns
-EINVAL directly:

mm/damon/core.c:damon_commit_filters() {
	...
	case DAMON_FILTER_TYPE_HUGEPAGE_SIZE:
		if (src_filter->range_max < src_filter->range_min)
			return -EINVAL;
		new_filter->range_min = src_filter->range_min;
		new_filter->range_max = src_filter->range_max;
		break;
	...
}

Returning directly bypasses damon_destroy_filter(), which leaves the newly
allocated new_filter orphaned. Because a local user with sysfs access can
repeatedly trigger this by writing invalid ranges and committing the state,
could this lead to a memory leak and potential memory exhaustion?

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

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

[SJ Park]

On Mon, 14 Sep 2026 14:54:03 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Missing range validation for hugepage_size filters in sysfs allows triggering a memory leak in the DAMON core.
> --
> 
> commit 2e8e2509774f21f3f602056d79fd21880b487fde
> Author: SJ Park <sj@kernel.org>
> 
> mm/damon/sysfs: support hugepage_size probe filter
> 
> Extend DAMON sysfs interface to support hugepage_size probe filter. Allows
> hugepage_size user string input to the filter type file and passes the size
> range argument via min/max files 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;
> >  		}
> >  		damon_add_filter(probe, filter);
> >  	}
> 
> [Severity: High]
> Does this code need validation to ensure sys_filter->range_min <=
> sys_filter->range_max before passing the values to the DAMON core?
> 
> If a local user configures a filter with a minimum value greater than the
> maximum value, this unvalidated input will reach damon_commit_filters() in
> mm/damon/core.c.
> 
> In damon_commit_filters(), the core detects the invalid range but returns
> -EINVAL directly:
> 
> mm/damon/core.c:damon_commit_filters() {
> 	...
> 	case DAMON_FILTER_TYPE_HUGEPAGE_SIZE:
> 		if (src_filter->range_max < src_filter->range_min)
> 			return -EINVAL;
> 		new_filter->range_min = src_filter->range_min;
> 		new_filter->range_max = src_filter->range_max;
> 		break;
> 	...
> }
> 
> Returning directly bypasses damon_destroy_filter(), which leaves the newly
> allocated new_filter orphaned. Because a local user with sysfs access can
> repeatedly trigger this by writing invalid ranges and committing the state,
> could this lead to a memory leak and potential memory exhaustion?

I will fix the leak in the next spin.

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


Thanks,
SJ

[RFC PATCH v2 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 v2 6/8] Docs/mm/damon/design: update for hugepage_size probe filter

[sashiko-bot]

> Update DAMON design document for the newly added hugepage_size data
> attribute probe 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/20260914144448.93732-1-sj@kernel.org?part=6

[RFC PATCH v2 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 v2 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/20260914144448.93732-1-sj@kernel.org?part=7

[RFC PATCH v2 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 v2 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/20260914144448.93732-1-sj@kernel.org?part=8