[PATCH v3 0/3] mm/damon/sysfs: fix memory leak and NULL dereference issues

[PATCH v3 0/3] mm/damon/sysfs: fix memory leak and NULL dereference issues

[SeongJae Park]

DAMON_SYSFS can leak memory under allocation failure, and do NULL
pointer dereference when a privileged user make wrong sequences of
control.  Fix those.

Changes from v2
(https://lore.kernel.org/20260320163559.178101-1-objecting@objecting.org)
- Wordsmith second patch commit message.
- Add NULL dereference trigger steps on the commit messages.
- Collect the valid Reviewed-by: from SJ for the second patch.
- Rebased to latest mm-new.
Changes from v1
(https://lore.kernel.org/20260319155742.186627-1-objecting@objecting.org)
- Check kdamond->contexts->nr from damon_sysfs_handle_cmd()
- Collect Reviewed-by: from SJ for the first and the third patch.

Josh Law (3):
  mm/damon/sysfs: fix param_ctx leak on damon_sysfs_new_test_ctx()
    failure
  mm/damon/sysfs: check contexts->nr before accessing contexts_arr[0]
  mm/damon/sysfs: check contexts->nr in repeat_call_fn

 mm/damon/sysfs.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)


base-commit: 42bc5b563370622d688719aa248a4c861839373a
-- 
2.47.3

[PATCH v3 1/3] mm/damon/sysfs: fix param_ctx leak on damon_sysfs_new_test_ctx() failure

[SeongJae Park]

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

[PATCH v3 2/3] mm/damon/sysfs: check contexts->nr before accessing contexts_arr[0]

[SeongJae Park]

From: Josh Law <objecting@objecting.org>

Multiple sysfs command paths dereference contexts_arr[0] without first
verifying that kdamond->contexts->nr == 1.  A user can set nr_contexts
to 0 via sysfs while DAMON is running, causing NULL pointer
dereferences.

In more detail, the issue can be triggered by privileged users like
below.

First, start DAMON and make contexts directory empty
(kdamond->contexts->nr == 0).

    # damo start
    # cd /sys/kernel/mm/damon/admin/kdamonds/0
    # echo 0 > contexts/nr_contexts

Then, each of below commands will cause the NULL pointer dereference.

    # echo update_schemes_stats > state
    # echo update_schemes_tried_regions > state
    # echo update_schemes_tried_bytes > state
    # echo update_schemes_effective_quotas > state
    # echo update_tuned_intervals > state

Guard all commands (except OFF) at the entry point of
damon_sysfs_handle_cmd().

Fixes: 0ac32b8affb5 ("mm/damon/sysfs: support DAMOS stats")
Cc: <stable@vger.kernel.org>	# 5.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 | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/damon/sysfs.c b/mm/damon/sysfs.c
index b573b9d607848..ddc30586c0e61 100644
--- a/mm/damon/sysfs.c
+++ b/mm/damon/sysfs.c
@@ -1749,6 +1749,9 @@ static int damon_sysfs_update_schemes_tried_regions(
 static int damon_sysfs_handle_cmd(enum damon_sysfs_cmd cmd,
 		struct damon_sysfs_kdamond *kdamond)
 {
+	if (cmd != DAMON_SYSFS_CMD_OFF && kdamond->contexts->nr != 1)
+		return -EINVAL;
+
 	switch (cmd) {
 	case DAMON_SYSFS_CMD_ON:
 		return damon_sysfs_turn_damon_on(kdamond);
-- 
2.47.3

[PATCH v3 3/3] mm/damon/sysfs: check contexts->nr in repeat_call_fn

[SeongJae Park]

From: Josh Law <objecting@objecting.org>

damon_sysfs_repeat_call_fn() calls damon_sysfs_upd_tuned_intervals(),
damon_sysfs_upd_schemes_stats(), and
damon_sysfs_upd_schemes_effective_quotas() without checking
contexts->nr.  If nr_contexts is set to 0 via sysfs while DAMON is
running, these functions dereference contexts_arr[0] and cause a NULL
pointer dereference.  Add the missing check.

For example, the issue can be reproduced using DAMON sysfs interface and
DAMON user-space tool (damo) [1] like below.

    $ sudo damo start --refresh_interval 1s
    $ echo 0 | sudo tee \
            /sys/kernel/mm/damon/admin/kdamonds/0/contexts/nr_contexts

[1] https://github.com/damonitor/damo

Link: https://patch.msgid.link/20260320163559.178101-3-objecting@objecting.org
Fixes: d809a7c64ba8 ("mm/damon/sysfs: implement refresh_ms file internal work")
Cc: <stable@vger.kernel.org> # 6.17.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 | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/damon/sysfs.c b/mm/damon/sysfs.c
index ddc30586c0e61..6a44a2f3d8fc9 100644
--- a/mm/damon/sysfs.c
+++ b/mm/damon/sysfs.c
@@ -1620,9 +1620,12 @@ static int damon_sysfs_repeat_call_fn(void *data)
 
 	if (!mutex_trylock(&damon_sysfs_lock))
 		return 0;
+	if (sysfs_kdamond->contexts->nr != 1)
+		goto out;
 	damon_sysfs_upd_tuned_intervals(sysfs_kdamond);
 	damon_sysfs_upd_schemes_stats(sysfs_kdamond);
 	damon_sysfs_upd_schemes_effective_quotas(sysfs_kdamond);
+out:
 	mutex_unlock(&damon_sysfs_lock);
 	return 0;
 }
-- 
2.47.3

Re: (sashiko review status) [PATCH v3 0/3] mm/damon/sysfs: fix memory leak and NULL dereference issues

[SeongJae Park]

Forwarding sashiko.dev review status for this thread.

# review url: https://sashiko.dev/#/patchset/20260321175427.86000-1-sj@kernel.org

- [PATCH v3 1/3] mm/damon/sysfs: fix param_ctx leak on damon_sysfs_new_test_ctx() failure
  - status: Reviewed
  - review: No issues found.
- [PATCH v3 2/3] mm/damon/sysfs: check contexts->nr before accessing contexts_arr[0]
  - status: Reviewed
  - review: No issues found.
- [PATCH v3 3/3] mm/damon/sysfs: check contexts->nr in repeat_call_fn
  - status: Reviewed

# hkml [1] generated a draft of this mail.  It can be regenerated
# using below command:
#
#     hkml patch sashiko_dev --thread_status --for_forwarding \
#             20260321175427.86000-1-sj@kernel.org
#
# [1] https://github.com/sjp38/hackermail


Thanks,
SJ

Re: [PATCH v3 3/3] mm/damon/sysfs: check contexts->nr in repeat_call_fn

[SeongJae Park]

Subject: (Sashiko) Re: [PATCH v3 3/3] mm/damon/sysfs: check contexts->nr in repeat_call_fn

Forwarding Sashiko review for doing discussions via mails.

# review url: https://sashiko.dev/#/patchset/20260321175427.86000-4-sj@kernel.org
# start of sashiko.dev inline review
commit 349107c02ee8a122119ac77a51451bb3d9311a34
Author: Josh Law <objecting@objecting.org>

mm/damon/sysfs: check contexts->nr in repeat_call_fn

damon_sysfs_repeat_call_fn() calls damon_sysfs_upd_tuned_intervals(),
damon_sysfs_upd_schemes_stats(), and
damon_sysfs_upd_schemes_effective_quotas() without checking
contexts->nr.  If nr_contexts is set to 0 via sysfs while DAMON is
running, these functions dereference contexts_arr[0] and cause a NULL
pointer dereference.  Add the missing check.

Link: https://patch.msgid.link/20260320163559.178101-3-objecting@objecting.org

> diff --git a/mm/damon/sysfs.c b/mm/damon/sysfs.c
> index ddc30586c0e6..6a44a2f3d8fc 100644
> --- a/mm/damon/sysfs.c
> +++ b/mm/damon/sysfs.c
> @@ -1620,9 +1620,12 @@ static int damon_sysfs_repeat_call_fn(void *data)
>  
>  	if (!mutex_trylock(&damon_sysfs_lock))
>  		return 0;
> +	if (sysfs_kdamond->contexts->nr != 1)
> +		goto out;
>  	damon_sysfs_upd_tuned_intervals(sysfs_kdamond);

Does this code cause starvation or incorrect statistics when multiple
kdamonds are active?

It appears that damon_sysfs_next_update_jiffies is declared as a static
global variable and used by this function to throttle updates:

static unsigned long damon_sysfs_next_update_jiffies;

static int damon_sysfs_repeat_call_fn(void *data)
{
    ...
    if (time_before(jiffies, damon_sysfs_next_update_jiffies))
        return 0;
    damon_sysfs_next_update_jiffies = jiffies +
        msecs_to_jiffies(sysfs_kdamond->refresh_ms);
    ...
}

If multiple kdamonds run concurrently, wouldn't they all share and
overwrite this single global timestamp?

If one kdamond sets the timestamp to a future value, another kdamond's
thread might incorrectly evaluate time_before() to true and skip its
update, potentially leading to starvation and incorrect sysfs
statistics for all but the winning kdamond.

>  	damon_sysfs_upd_schemes_stats(sysfs_kdamond);
>  	damon_sysfs_upd_schemes_effective_quotas(sysfs_kdamond);
> +out:
>  	mutex_unlock(&damon_sysfs_lock);
>  	return 0;
>  }

Could there also be a memory leak of repeat_call_control in
damon_sysfs_turn_damon_on() if the target kdamond exits early?

In damon_sysfs_turn_damon_on(), repeat_call_control is allocated:

    repeat_call_control = kmalloc_obj(*repeat_call_control);

If the kdamond thread encounters an error or has no work, it can exit
and set ctx->kdamond = NULL before damon_call() is fully executed.

In this race window, if damon_call() detects that the context is
inactive it calls damon_call_handle_inactive_ctx(). This removes the
control from the list and returns -EINVAL, but it does not free the
memory.

Because damon_sysfs_turn_damon_on() ignores the return value of
damon_call(), does this result in a permanent leak of the memory
allocated for repeat_call_control?


# end of sashiko.dev inline review
# review url: https://sashiko.dev/#/patchset/20260321175427.86000-4-sj@kernel.org
#
# hkml [1] generated a draft of this mail.  It can be regenerated
# using below command:
#
#     hkml patch sashiko_dev --for_forwarding \
#             20260321175427.86000-4-sj@kernel.org
#
# [1] https://github.com/sjp38/hackermail

Sent using hkml (https://github.com/sjp38/hackermail)

Re: [PATCH v3 3/3] mm/damon/sysfs: check contexts->nr in repeat_call_fn

[SeongJae Park]

TL; DR: no blocker for this patch is found.

On Sat, 21 Mar 2026 13:05:22 -0700 SeongJae Park <sj@kernel.org> wrote:

> Subject: (Sashiko) Re: [PATCH v3 3/3] mm/damon/sysfs: check contexts->nr in repeat_call_fn
> 
> Forwarding Sashiko review for doing discussions via mails.
> 
> # review url: https://sashiko.dev/#/patchset/20260321175427.86000-4-sj@kernel.org
> # start of sashiko.dev inline review
> commit 349107c02ee8a122119ac77a51451bb3d9311a34
> Author: Josh Law <objecting@objecting.org>
> 
> mm/damon/sysfs: check contexts->nr in repeat_call_fn
> 
> damon_sysfs_repeat_call_fn() calls damon_sysfs_upd_tuned_intervals(),
> damon_sysfs_upd_schemes_stats(), and
> damon_sysfs_upd_schemes_effective_quotas() without checking
> contexts->nr.  If nr_contexts is set to 0 via sysfs while DAMON is
> running, these functions dereference contexts_arr[0] and cause a NULL
> pointer dereference.  Add the missing check.
> 
> Link: https://patch.msgid.link/20260320163559.178101-3-objecting@objecting.org
> 
> > diff --git a/mm/damon/sysfs.c b/mm/damon/sysfs.c
> > index ddc30586c0e6..6a44a2f3d8fc 100644
> > --- a/mm/damon/sysfs.c
> > +++ b/mm/damon/sysfs.c
> > @@ -1620,9 +1620,12 @@ static int damon_sysfs_repeat_call_fn(void *data)
> >  
> >  	if (!mutex_trylock(&damon_sysfs_lock))
> >  		return 0;
> > +	if (sysfs_kdamond->contexts->nr != 1)
> > +		goto out;
> >  	damon_sysfs_upd_tuned_intervals(sysfs_kdamond);
> 
> Does this code cause starvation or incorrect statistics when multiple
> kdamonds are active?
> 
> It appears that damon_sysfs_next_update_jiffies is declared as a static
> global variable and used by this function to throttle updates:
> 
> static unsigned long damon_sysfs_next_update_jiffies;
> 
> static int damon_sysfs_repeat_call_fn(void *data)
> {
>     ...
>     if (time_before(jiffies, damon_sysfs_next_update_jiffies))
>         return 0;
>     damon_sysfs_next_update_jiffies = jiffies +
>         msecs_to_jiffies(sysfs_kdamond->refresh_ms);
>     ...
> }
> 
> If multiple kdamonds run concurrently, wouldn't they all share and
> overwrite this single global timestamp?
> 
> If one kdamond sets the timestamp to a future value, another kdamond's
> thread might incorrectly evaluate time_before() to true and skip its
> update, potentially leading to starvation and incorrect sysfs
> statistics for all but the winning kdamond.

I answered this in the previous version of this patch.  In short, good finding
but not a blocker of this patch, I will work on it.

> 
> >  	damon_sysfs_upd_schemes_stats(sysfs_kdamond);
> >  	damon_sysfs_upd_schemes_effective_quotas(sysfs_kdamond);
> > +out:
> >  	mutex_unlock(&damon_sysfs_lock);
> >  	return 0;
> >  }
> 
> Could there also be a memory leak of repeat_call_control in
> damon_sysfs_turn_damon_on() if the target kdamond exits early?
> 
> In damon_sysfs_turn_damon_on(), repeat_call_control is allocated:
> 
>     repeat_call_control = kmalloc_obj(*repeat_call_control);
> 
> If the kdamond thread encounters an error or has no work, it can exit
> and set ctx->kdamond = NULL before damon_call() is fully executed.
> 
> In this race window, if damon_call() detects that the context is
> inactive it calls damon_call_handle_inactive_ctx(). This removes the
> control from the list and returns -EINVAL, but it does not free the
> memory.
> 
> Because damon_sysfs_turn_damon_on() ignores the return value of
> damon_call(), does this result in a permanent leak of the memory
> allocated for repeat_call_control?

I answered this in the previous version of this patch.  In short, good finding
but not a blocker of this patch, I will work on it.

> 
> 
> # end of sashiko.dev inline review
> # review url: https://sashiko.dev/#/patchset/20260321175427.86000-4-sj@kernel.org


Thanks,
SJ

[...]

Re: [PATCH v3 1/3] mm/damon/sysfs: fix param_ctx leak on damon_sysfs_new_test_ctx() failure

[Markus Elfring]

> 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

Re: [PATCH v3 1/3] mm/damon/sysfs: fix param_ctx leak on damon_sysfs_new_test_ctx() failure

[Josh Law]

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

Re: [v3 1/3] mm/damon/sysfs: fix param_ctx leak on damon_sysfs_new_test_ctx() failure

[Markus Elfring]

> Markus these patches are already merged

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

Regards,
Markus

Re: [v3 1/3] mm/damon/sysfs: fix param_ctx leak on damon_sysfs_new_test_ctx() failure

[SeongJae Park]

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

[...]

Re: [v3 1/3] mm/damon/sysfs: fix param_ctx leak on damon_sysfs_new_test_ctx() failure

[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

Re: [v3 1/3] mm/damon/sysfs: fix param_ctx leak on damon_sysfs_new_test_ctx() failure

[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
>
>[...]



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

Re: [v3 1/3] mm/damon/sysfs: fix param_ctx leak on damon_sysfs_new_test_ctx() failure

[SeongJae Park]

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

[...]

Re: [v3 1/3] mm/damon/sysfs: fix param_ctx leak on damon_sysfs_new_test_ctx() failure

[Josh Law]

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

Re: [v3 1/3] mm/damon/sysfs: fix param_ctx leak on damon_sysfs_new_test_ctx() failure

[SeongJae Park]

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

[...]

Re: [v3 1/3] mm/damon/sysfs: fix param_ctx leak on damon_sysfs_new_test_ctx() failure

[Josh Law]

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