From: SeongJae Park <sj@kernel.org>
Cc: SeongJae Park <sj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Yang Yingliang <yangyingliang@huawei.com>,
damon@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: [RFC PATCH 1/5] mm/damon/core: fix wrong end address assignment on walk_system_ram()
Date: Wed, 4 Mar 2026 21:39:13 -0800 [thread overview]
Message-ID: <20260305053918.83786-2-sj@kernel.org> (raw)
In-Reply-To: <20260305053918.83786-1-sj@kernel.org>
'struct damon_addr_range' and 'struct resource' represent different
types of address ranges. 'damon_addr_range' is for end-open ranges
([start, end)). 'resource' is for fully-closed ranges ([start, end]).
But walk_system_ram() is assigning resource->end to
damon_addr_range->end without the inclusiveness adjustment. As a
result, the function returns an address range that is same as the
expected one, but missing the last one byte.
The function is being used to find and set the biggest system ram as the
default monitoring target for DAMON_RECLAIM and DAMON_LRU_SORT. Missing
the last byte of the big range shouldn't be a real problem for the real
use cases. That said, the loss is definitely an unintended behavior.
Do the correct adjustment.
Fixes: 43b0536cb471 ("mm/damon: introduce DAMON-based Reclamation (DAMON_RECLAIM)")
Signed-off-by: SeongJae Park <sj@kernel.org>
---
mm/damon/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/damon/core.c b/mm/damon/core.c
index de38f2356b72b..db388d05cac3f 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -3056,7 +3056,7 @@ static int walk_system_ram(struct resource *res, void *arg)
if (a->end - a->start < resource_size(res)) {
a->start = res->start;
- a->end = res->end;
+ a->end = res->end + 1;
}
return 0;
}
--
2.47.3
next prev parent reply other threads:[~2026-03-05 5:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-05 5:39 [RFC PATCH 0/5] mm/damon: support addr_unit on default monitoring targets for modules SeongJae Park
2026-03-05 5:39 ` SeongJae Park [this message]
2026-03-05 5:39 ` [RFC PATCH 2/5] mm/damon/core: support addr_unit on damon_find_biggest_system_ram() SeongJae Park
2026-03-05 5:39 ` [RFC PATCH 3/5] mm/damon/core: receive addr_unit on damon_set_region_biggest_system_ram_default() SeongJae Park
2026-03-05 5:39 ` [RFC PATCH 4/5] mm/damon/reclaim: respect addr_unit on default monitoring region setup SeongJae Park
2026-03-05 5:39 ` [RFC PATCH 5/5] mm/damon/lru_sort: " SeongJae Park
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260305053918.83786-2-sj@kernel.org \
--to=sj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=damon@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=yangyingliang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox