[PATCH] mm/damon/core: fix potential memory leak by cleaning ops_filter in damon_destroy_scheme

[PATCH] mm/damon/core: fix potential memory leak by cleaning ops_filter in damon_destroy_scheme

[Enze Li]

Currently, damon_destroy_scheme() only cleans up the filter list but
leaves ops_filter untouched, which could lead to memory leaks when
a scheme is destroyed.

This patch ensures both filter and ops_filter are properly freed in
damon_destroy_scheme(), preventing potential memory leaks.

Fixes: ab82e57981d0 ("mm/damon/core: introduce damos->ops_filters")
Signed-off-by: Enze Li <lienze@kylinos.cn>
---
 mm/damon/core.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/damon/core.c b/mm/damon/core.c
index 93848b4c6944..3e2c743e0864 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -452,6 +452,9 @@ void damon_destroy_scheme(struct damos *s)
 	damos_for_each_filter_safe(f, next, s)
 		damos_destroy_filter(f);
 
+	damos_for_each_ops_filter_safe(f, next, s)
+		damos_destroy_filter(f);
+
 	kfree(s->migrate_dests.node_id_arr);
 	kfree(s->migrate_dests.weight_arr);
 	damon_del_scheme(s);

base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
-- 
2.51.0

Re: [PATCH] mm/damon/core: fix potential memory leak by cleaning ops_filter in damon_destroy_scheme

[SeongJae Park]

On Tue, 14 Oct 2025 16:42:25 +0800 Enze Li <lienze@kylinos.cn> wrote:

> Currently, damon_destroy_scheme() only cleans up the filter list but
> leaves ops_filter untouched, which could lead to memory leaks when
> a scheme is destroyed.
> 
> This patch ensures both filter and ops_filter are properly freed in
> damon_destroy_scheme(), preventing potential memory leaks.

Thank you for fixing this!

FYI the leak is not only potential but can easily be reproduced using the ops
damos filters.  For example, I was able to reproduce it using DAMON user-space
tool (damo), like below.

    $ sudo ./damo start
    $ sudo ./damo report access --snapshot_damos_filter allow anon

After the above steps I confirmed it leaks the memory using kmemleak.

> 
> Fixes: ab82e57981d0 ("mm/damon/core: introduce damos->ops_filters")
> Signed-off-by: Enze Li <lienze@kylinos.cn>

Reviewed-by: SeongJae Park <sj@kernel.org>


Thanks,
SJ

[...]

Re: [PATCH] mm/damon/core: fix potential memory leak by cleaning ops_filter in damon_destroy_scheme

[Enze Li]

Hi SJ,

On Tue, Oct 14 2025 at 11:25:38 AM -0700, SeongJae Park wrote:

> On Tue, 14 Oct 2025 16:42:25 +0800 Enze Li <lienze@kylinos.cn> wrote:
>
>> Currently, damon_destroy_scheme() only cleans up the filter list but
>> leaves ops_filter untouched, which could lead to memory leaks when
>> a scheme is destroyed.
>> 
>> This patch ensures both filter and ops_filter are properly freed in
>> damon_destroy_scheme(), preventing potential memory leaks.
>
> Thank you for fixing this!
>
> FYI the leak is not only potential but can easily be reproduced using the ops
> damos filters.  For example, I was able to reproduce it using DAMON user-space
> tool (damo), like below.
>
>     $ sudo ./damo start
>     $ sudo ./damo report access --snapshot_damos_filter allow anon
>
> After the above steps I confirmed it leaks the memory using kmemleak.

Thank you for the review.

Considering that similar memory leak issues might occur elsewhere in the
future, should we consider exploring the introduction of Rust for
certain modules as a proactive measure?

My search through the mailing list archives didn't reveal similar
discussions, though I might have missed them.  Would you be open to
sharing your insights on this matter?

Best Regards,
Enze

<...>

Re: [PATCH] mm/damon/core: fix potential memory leak by cleaning ops_filter in damon_destroy_scheme

[SeongJae Park]

On Wed, 15 Oct 2025 10:46:47 +0800 Enze Li <lienze@kylinos.cn> wrote:

> Hi SJ,
> 
> On Tue, Oct 14 2025 at 11:25:38 AM -0700, SeongJae Park wrote:
> 
> > On Tue, 14 Oct 2025 16:42:25 +0800 Enze Li <lienze@kylinos.cn> wrote:
> >
> >> Currently, damon_destroy_scheme() only cleans up the filter list but
> >> leaves ops_filter untouched, which could lead to memory leaks when
> >> a scheme is destroyed.
> >> 
> >> This patch ensures both filter and ops_filter are properly freed in
> >> damon_destroy_scheme(), preventing potential memory leaks.
> >
> > Thank you for fixing this!
> >
> > FYI the leak is not only potential but can easily be reproduced using the ops
> > damos filters.  For example, I was able to reproduce it using DAMON user-space
> > tool (damo), like below.
> >
> >     $ sudo ./damo start
> >     $ sudo ./damo report access --snapshot_damos_filter allow anon
> >
> > After the above steps I confirmed it leaks the memory using kmemleak.
> 
> Thank you for the review.
> 
> Considering that similar memory leak issues might occur elsewhere in the
> future, should we consider exploring the introduction of Rust for
> certain modules as a proactive measure?
> 
> My search through the mailing list archives didn't reveal similar
> discussions, though I might have missed them.

I also don't remember discussing Rust for DAMON on the mailing list.  You must
be right, or I also missed some :)

> Would you be open to
> sharing your insights on this matter?

In short, I agree adopting Rust for DAMON could be helpful.  As you mentioned,
rewriting certain buggy DAMON modules such as DAMON sysfs interface in Rust
could be a good idea.  There was also a private discussion about writing DAMON
user-space tool or library in Rust.  I think that could also be an interesting
idea.  So I'd say I'm open to Rust adoption on DAMON, not only in kernel space
but also in user-space.

Nonetheless, I know nothing about Rust, and having limited resource.  I
actually wanted to learn Rust and start writing a sample DAMON module in Rust.
I got the idea from the last year LPC, but still made no progress at all.  So
I'm open to Rust adoption in long term, but cannot guarantee something in short
term for now.

The user-space Rust adoption could be done regardless of my help, though.  That
is, someone could develop and maintain a new user-space tool or library for
DAMON with Rust, independent of 'damo'.  My poor knowledge about Rush shouldn't
be a blocker for such projects.


Thanks,
SJ

[...]