Re: [RFC PATCH v2.2 22/28] mm/damon/core: introduce DAMON_FILTER_TYPE_MEMCG

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Newly appended DAMON filters in `damon_commit_filters()` fail to copy the `memcg_id` field, leaving it uninitialized.
--

commit 01e48275cc904a624a318c3fbc6c7313978207ef
Author: SeongJae Park <sj@kernel.org>

mm/damon/core: introduce DAMON_FILTER_TYPE_MEMCG

This commit introduces a new DAMON filter type, DAMON_FILTER_TYPE_MEMCG,
which allows monitoring and filtering based on specific memory cgroups.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index ab8ac9ec8450d..2d4a63dcc47fe 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -1422,6 +1422,13 @@ static void damon_commit_filter(struct damon_filter *dst,
>  	dst->type = src->type;
>  	dst->matching = src->matching;
>  	dst->allow = src->allow;
> +	switch (dst->type) {
> +	case DAMON_FILTER_TYPE_MEMCG:
> +		dst->memcg_id = src->memcg_id;
> +		break;
> +	default:
> +		break;
> +	}
>  }
>  
>  static int damon_commit_filters(struct damon_probe *dst,

When new filters are appended during probe synchronization, does the
memcg_id field remain uninitialized?

Looking at damon_commit_filters() which immediately follows this function,
it creates new filters for any remaining source filters:

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

Since damon_new_filter() only initializes the type, matching, and allow
fields, and memcg_id is not manually copied here like it is in
damon_commit_filter(), could this leave the newly appended filter's
memcg_id with uninitialized memory?

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