From: Josh Law <objecting@objecting.org>

When damon_sysfs_new_test_ctx() fails in damon_sysfs_commit_input(),
param_ctx is leaked because the early return skips the cleanup at the
out label. Destroy param_ctx before returning.

Fixes: f0c5118ebb0e ("mm/damon/sysfs: catch commit test ctx alloc failure")
Cc: <stable@vger.kernel.org> # 6.18.x
Signed-off-by: Josh Law <objecting@objecting.org>
Reviewed-by: SeongJae Park <sj@kernel.org>
Signed-off-by: SeongJae Park <sj@kernel.org>
---
 mm/damon/sysfs.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/mm/damon/sysfs.c b/mm/damon/sysfs.c
index 576d1ddd736bf..b573b9d607848 100644
--- a/mm/damon/sysfs.c
+++ b/mm/damon/sysfs.c
@@ -1524,8 +1524,10 @@ static int damon_sysfs_commit_input(void *data)
 	if (IS_ERR(param_ctx))
 		return PTR_ERR(param_ctx);
 	test_ctx = damon_sysfs_new_test_ctx(kdamond->damon_ctx);
-	if (!test_ctx)
+	if (!test_ctx) {
+		damon_destroy_ctx(param_ctx);
 		return -ENOMEM;
+	}
 	err = damon_commit_ctx(test_ctx, param_ctx);
 	if (err)
 		goto out;
-- 
2.47.3

> When damon_sysfs_new_test_ctx() fails in damon_sysfs_commit_input(),
> param_ctx is leaked because the early return skips the cleanup at the
> out label. Destroy param_ctx before returning.

Will it become helpful to use another label accordingly?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?h=v7.0-rc5#n526
https://elixir.bootlin.com/linux/v7.0-rc4/source/mm/damon/sysfs.c#L1506-L1537

Regards,
Markus

On 23 March 2026 07:28:59 GMT, Markus Elfring <Markus.Elfring@web.de> wrote:
>> When damon_sysfs_new_test_ctx() fails in damon_sysfs_commit_input(),
>> param_ctx is leaked because the early return skips the cleanup at the
>> out label. Destroy param_ctx before returning.
>
>Will it become helpful to use another label accordingly?
>https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?h=v7.0-rc5#n526
>https://elixir.bootlin.com/linux/v7.0-rc4/source/mm/damon/sysfs.c#L1506-L1537
>
>Regards,
>Markus



Markus these patches are already merged 


V/R


Josh Law

> Markus these patches are already merged

Are there still development interests for the application of a better goto chain?

Regards,
Markus

On Mon, 23 Mar 2026 09:25:52 +0100 Markus Elfring <Markus.Elfring@web.de> wrote:

> > Markus these patches are already merged

It's still in mm-hotfixes-unstable.  We can still make changes if needed.

I understand what Markus is suggesting is adding another goto label to make
the flow cleaner.  Because this is a hotfix that aims to be also applied to
stable kernels, I think the change is better to be as simple as possible.
Adding another goto label could make it better, but I'm concerned if it will
make porting difficult.

IMHO, it is better to do that as a followup cleanup, rather than make change
into the hotfix.  Let me know if this change is somewhat critical and I'm
missing that.

> 
> Are there still development interests for the application of a better goto chain?

Sure, if it makes it better, why not? :)


Thanks,
SJ

[...]

On 23 March 2026 15:24:52 GMT, SeongJae Park <sj@kernel.org> wrote:
>On Mon, 23 Mar 2026 09:25:52 +0100 Markus Elfring <Markus.Elfring@web.de> wrote:
>
>> > Markus these patches are already merged
>
>It's still in mm-hotfixes-unstable.  We can still make changes if needed.
>
>I understand what Markus is suggesting is adding another goto label to make
>the flow cleaner.  Because this is a hotfix that aims to be also applied to
>stable kernels, I think the change is better to be as simple as possible.
>Adding another goto label could make it better, but I'm concerned if it will
>make porting difficult.
>
>IMHO, it is better to do that as a followup cleanup, rather than make change
>into the hotfix.  Let me know if this change is somewhat critical and I'm
>missing that.
>
>> 
>> Are there still development interests for the application of a better goto chain?
>
>Sure, if it makes it better, why not? :)
>
>
>Thanks,
>SJ
>
>[...]



Also, unconnected to our topic!


I've tried to backport Damon to 4.19 (for a personal android thing, and failed! Of course)

Can I have a bit of help if that's fine with you? The tree is based on GitHub a bit


V/R


Josh Law

On Mon, 23 Mar 2026 16:48:19 +0000 Josh Law <objecting@objecting.org> wrote:
[...]
> Also, unconnected to our topic!
> 
> 
> I've tried to backport Damon to 4.19 (for a personal android thing, and failed! Of course)
> 
> Can I have a bit of help if that's fine with you? The tree is based on GitHub a bit

Sure, I will be happy to help as much as I can without burning myself ;)

Seems [1] Alma Linux has backported DAMON on their 4.18 kernel.  Maybe you can
try their port first?

Also, what is the oldest kernel that you have to use?  As newer it is, the
backporting will be easier.  When I was in AWS, I backported DAMON of v6.7 on
the v5.10 based Amazon Linux kernel, and the source is available on GitHub.  So
if you can use 5.10 based kernel, using that could also be a good option.

[1] https://oracle.github.io/kconfigs/?config=UTS_RELEASE&config=DAMON


Thanks,
SJ

[...]

On 24 March 2026 00:14:59 GMT, SeongJae Park <sj@kernel.org> wrote:
>On Mon, 23 Mar 2026 16:48:19 +0000 Josh Law <objecting@objecting.org> wrote:
>[...]
>> Also, unconnected to our topic!
>> 
>> 
>> I've tried to backport Damon to 4.19 (for a personal android thing, and failed! Of course)
>> 
>> Can I have a bit of help if that's fine with you? The tree is based on GitHub a bit
>
>Sure, I will be happy to help as much as I can without burning myself ;)
>
>Seems [1] Alma Linux has backported DAMON on their 4.18 kernel.  Maybe you can
>try their port first?
>
>Also, what is the oldest kernel that you have to use?  As newer it is, the
>backporting will be easier.  When I was in AWS, I backported DAMON of v6.7 on
>the v5.10 based Amazon Linux kernel, and the source is available on GitHub.  So
>if you can use 5.10 based kernel, using that could also be a good option.
>
>[1] https://oracle.github.io/kconfigs/?config=UTS_RELEASE&config=DAMON
>
>
>Thanks,
>SJ
>
>[...]



well android likes using old kernels for some reasons, especially LTS, so 4.19..

V/R


Josh Law

On Tue, 24 Mar 2026 07:06:25 +0000 Josh Law <objecting@objecting.org> wrote:

> 
> 
> On 24 March 2026 00:14:59 GMT, SeongJae Park <sj@kernel.org> wrote:
> >On Mon, 23 Mar 2026 16:48:19 +0000 Josh Law <objecting@objecting.org> wrote:
> >[...]
> >> Also, unconnected to our topic!
> >> 
> >> 
> >> I've tried to backport Damon to 4.19 (for a personal android thing, and failed! Of course)
> >> 
> >> Can I have a bit of help if that's fine with you? The tree is based on GitHub a bit
> >
> >Sure, I will be happy to help as much as I can without burning myself ;)
> >
> >Seems [1] Alma Linux has backported DAMON on their 4.18 kernel.  Maybe you can
> >try their port first?
> >
> >Also, what is the oldest kernel that you have to use?  As newer it is, the
> >backporting will be easier.  When I was in AWS, I backported DAMON of v6.7 on
> >the v5.10 based Amazon Linux kernel, and the source is available on GitHub.  So
> >if you can use 5.10 based kernel, using that could also be a good option.
> >
> >[1] https://oracle.github.io/kconfigs/?config=UTS_RELEASE&config=DAMON
> >
> >
> >Thanks,
> >SJ
> >
> >[...]
> 
> 
> 
> well android likes using old kernels for some reasons, especially LTS, so 4.19..

Well, but the long term support of 4.19 has dead a few years ago.  The oldest
LTS kernel of today is 5.10 [1].  I understand some vendors might still use
4.19 kernel, though.  Anyway, let me know if there is anything that I can help.
I will try to help.

[1] https://www.kernel.org/category/releases.html


Thanks,
SJ

[...]

On 24 March 2026 14:15:37 GMT, SeongJae Park <sj@kernel.org> wrote:
>On Tue, 24 Mar 2026 07:06:25 +0000 Josh Law <objecting@objecting.org> wrote:
>
>> 
>> 
>> On 24 March 2026 00:14:59 GMT, SeongJae Park <sj@kernel.org> wrote:
>> >On Mon, 23 Mar 2026 16:48:19 +0000 Josh Law <objecting@objecting.org> wrote:
>> >[...]
>> >> Also, unconnected to our topic!
>> >> 
>> >> 
>> >> I've tried to backport Damon to 4.19 (for a personal android thing, and failed! Of course)
>> >> 
>> >> Can I have a bit of help if that's fine with you? The tree is based on GitHub a bit
>> >
>> >Sure, I will be happy to help as much as I can without burning myself ;)
>> >
>> >Seems [1] Alma Linux has backported DAMON on their 4.18 kernel.  Maybe you can
>> >try their port first?
>> >
>> >Also, what is the oldest kernel that you have to use?  As newer it is, the
>> >backporting will be easier.  When I was in AWS, I backported DAMON of v6.7 on
>> >the v5.10 based Amazon Linux kernel, and the source is available on GitHub.  So
>> >if you can use 5.10 based kernel, using that could also be a good option.
>> >
>> >[1] https://oracle.github.io/kconfigs/?config=UTS_RELEASE&config=DAMON
>> >
>> >
>> >Thanks,
>> >SJ
>> >
>> >[...]
>> 
>> 
>> 
>> well android likes using old kernels for some reasons, especially LTS, so 4.19..
>
>Well, but the long term support of 4.19 has dead a few years ago.  The oldest
>LTS kernel of today is 5.10 [1].  I understand some vendors might still use
>4.19 kernel, though.  Anyway, let me know if there is anything that I can help.
>I will try to help.
>
>[1] https://www.kernel.org/category/releases.html
>
>
>Thanks,
>SJ
>
>[...]


The device itself is unsupported (Galaxy S20 FE)

I've been working on a kernel for this device for quite a long time 

V/R

Josh Law

On 23 March 2026 15:24:52 GMT, SeongJae Park <sj@kernel.org> wrote:
>On Mon, 23 Mar 2026 09:25:52 +0100 Markus Elfring <Markus.Elfring@web.de> wrote:
>
>> > Markus these patches are already merged
>
>It's still in mm-hotfixes-unstable.  We can still make changes if needed.
>
>I understand what Markus is suggesting is adding another goto label to make
>the flow cleaner.  Because this is a hotfix that aims to be also applied to
>stable kernels, I think the change is better to be as simple as possible.
>Adding another goto label could make it better, but I'm concerned if it will
>make porting difficult.
>
>IMHO, it is better to do that as a followup cleanup, rather than make change
>into the hotfix.  Let me know if this change is somewhat critical and I'm
>missing that.
>
>> 
>> Are there still development interests for the application of a better goto chain?
>
>Sure, if it makes it better, why not? :)
>
>
>Thanks,
>SJ
>
>[...]


Yeah, I understand where he's going with this, but I'll possibly make cleanup patches soon

V/R


Josh Law