FAILED: patch "[PATCH] samples/damon/mtier: fail early if address range parameters" failed to apply to 7.1-stable tree
Subsystems (2)
[email protected]
maintainerThe patch below does not apply to the 7.1-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-7.1.y
git checkout FETCH_HEAD
git cherry-pick -x 7746d72c64054976887928d64d2caf25c5a6dcc0
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<[email protected]>' --in-reply-to '2026072007-eldercare-amusing-37b4@gregkh' --subject-prefix 'PATCH 7.1.y' 'HEAD^..'
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 7746d72c64054976887928d64d2caf25c5a6dcc0 Mon Sep 17 00:00:00 2001
From: Zenghui Yu <[email protected]>
Date: Mon, 29 Jun 2026 07:44:31 -0700
Subject: [PATCH] samples/damon/mtier: fail early if address range parameters
are invalid
The comment on top of struct damon_region clearly says that
For any use case, @ar should be non-zero positive size.
which is now verified in damon_verify_new_region() if the kernel is built with DAMON_DEBUG_SANITY.
The WARN_ONCE() can be triggered if the mtier sample module is enabled before node{0,1}_{start,end}_addr have been properly initialized, which is obviously not good.
------------[ cut here ]------------ start 0 >= end 0 WARNING: mm/damon/core.c:217 at damon_new_region+0xf4/0x118, CPU#59: bash/341468 Call trace: damon_new_region+0xf4/0x118 (P) damon_set_regions+0xfc/0x3c0 damon_sample_mtier_build_ctx+0xe8/0x3a8 damon_sample_mtier_start+0x1c/0x90 damon_sample_mtier_enable_store+0x98/0xb0 param_attr_store+0xb4/0x128 module_attr_store+0x2c/0x50 sysfs_kf_write+0x58/0x90 kernfs_fop_write_iter+0x16c/0x238 vfs_write+0x2c0/0x370 ksys_write+0x74/0x118 __arm64_sys_write+0x24/0x38 invoke_syscall+0xa8/0x118 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x54/0x370 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0 ---[ end trace 0000000000000000 ]---
Note that the same issue can happen if detect_node_addresses is true, and node 0 or 1 is memoryless. Fix it together by checking the validity of parameters right before damon_new_region() and fail early if they're invalid.
samples/damon/mtier.c +3 -0
@@ -120,6 +120,9 @@ static struct damon_ctx *damon_sample_mtier_build_ctx(bool promote) addr.end = promote ? node1_end_addr : node0_end_addr; } +if (addr.start >= addr.end) + goto free_out; + range.start = addr.start; range.end = addr.end;
SJ Park
maintainerPATCH 1/1 samples/damon/mtier: fail early if address range parameters are invalid
From: Zenghui Yu <[email protected]>
The comment on top of struct damon_region clearly says that
For any use case, @ar should be non-zero positive size.
which is now verified in damon_verify_new_region() if the kernel is built with DAMON_DEBUG_SANITY.
The WARN_ONCE() can be triggered if the mtier sample module is enabled before node{0,1}_{start,end}_addr have been properly initialized, which is obviously not good.
------------[ cut here ]------------ start 0 >= end 0 WARNING: mm/damon/core.c:217 at damon_new_region+0xf4/0x118, CPU#59: bash/341468 Call trace: damon_new_region+0xf4/0x118 (P) damon_set_regions+0xfc/0x3c0 damon_sample_mtier_build_ctx+0xe8/0x3a8 damon_sample_mtier_start+0x1c/0x90 damon_sample_mtier_enable_store+0x98/0xb0 param_attr_store+0xb4/0x128 module_attr_store+0x2c/0x50 sysfs_kf_write+0x58/0x90 kernfs_fop_write_iter+0x16c/0x238 vfs_write+0x2c0/0x370 ksys_write+0x74/0x118 __arm64_sys_write+0x24/0x38 invoke_syscall+0xa8/0x118 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x54/0x370 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0 ---[ end trace 0000000000000000 ]---
Note that the same issue can happen if detect_node_addresses is true, and node 0 or 1 is memoryless. Fix it together by checking the validity of parameters right before damon_new_region() and fail early if they're invalid.
--- samples/damon/mtier.c | 3 +++ 1 file changed, 3 insertions(+)
samples/damon/mtier.c +3 -0
@@ -120,6 +120,9 @@ static struct damon_ctx *damon_sample_mtier_build_ctx(bool promote) addr.end = promote ? node1_end_addr : node0_end_addr; } +if (addr.start >= addr.end) + goto free_out; + region =damon_new_region (addr.start, addr.end);if (!region) goto free_out;
Signature · 1 line
2.47.3
[email protected]
AI reviewRe: [PATCH 7.1.y] samples/damon/mtier: fail early if address range parameters are invalid
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Resource leaks (memory, kthreads, struct pid) on failure paths in DAMON sample modules. --
--- Patch [1]: [PATCH 7.1.y] samples/damon/mtier: fail early if address range parameters are invalid --- commit 999f01f2d7c2530ae577d445b6761ac7a2a10e77
Author: Zenghui Yu <[email protected]>
samples/damon/mtier: fail early if address range parameters are invalid
This commit prevents a WARN_ONCE() trigger in the damon mtier sample module by validating that node{0,1}_{start,end}_addr specify a valid region before passing them to damon_new_region().
Quoted 5 lines
samples/damon/mtier.c +0
-0
samples/damon/mtier.c static struct damon_ctx *damon_sample_mtier_build_ctx(bool promote) · line 128
Quoted 9 lines
samples/damon/mtier.c +3
-0@@ -120,6 +120,9 @@ static struct damon_ctx *damon_sample_mtier_build_ctx(bool promote) addr.end = promote ? node1_end_addr : node0_end_addr; } +if (addr.start >= addr.end) + goto free_out; + region =damon_new_region (addr.start, addr.end);if (!region) goto free_out;
[Severity: High]
This is a pre-existing issue, but does damon_sample_mtier_start() leak memory and running kthreads on failure?
Looking at samples/damon/mtier.c:damon_sample_mtier_start():
return damon_start(ctxs, 2, true);
If damon_start() succeeds for the first context but fails for the second, the error is returned directly. This leaves the first context running indefinitely, leaking both the damon_ctx objects and the started kthreads. This would hold the damon core's exclusive flag, preventing future exclusive monitoring on the system until reboot.
A similar issue appears in samples/damon/prcl.c:damon_sample_prcl_start():
err = damon_start(&ctx, 1, true); if (err) return err; repeat_call_control.data = ctx; return damon_call(ctx, &repeat_call_control);
And in samples/damon/wsse.c:damon_sample_wsse_start():
err = damon_start(&ctx, 1, true); if (err) return err; repeat_call_control.data = ctx; return damon_call(ctx, &repeat_call_control);
If damon_call() fails, the functions return the error immediately without stopping the started threads or destroying the contexts. This also bypasses damon_destroy_ctx(), leading to a struct pid reference leak.
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1