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

[sashiko-bot@kernel.org]

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