Re: [PATCH] mm/damon: unify address range representation with damon_addr_range

[SeongJae Park <sj@kernel.org>]

On Fri, 30 Jan 2026 17:56:41 -0800 SeongJae Park <sj@kernel.org> wrote:

> On Thu, 29 Jan 2026 19:38:45 -0800 SeongJae Park <sj@kernel.org> wrote:
> 
> > Hello Quanmin,
> > 
> > On Fri, 30 Jan 2026 11:07:08 +0800 Quanmin Yan <yanquanmin1@huawei.com> wrote:
> [...]
> > > Actually, DAMON only actively searches for the biggest System RAM
> > > address when the user does not set a monitoring region. In this case,
> > > we always reset addr_unit to 1, which essentially restricts DAMON’s
> > > monitorable address range to 0–UL. Therefore, the described situation
> > > does not occur. For details, please refer to commit [1].
> > 
> > Again, you are correct.  There is no user scenario that can trigger the
> > problematic situation in the real world.  Nevertheless, assigning
> > 'resource_size_t' value to 'unsigned long' storage makes no sense, so I'm
> > calling such things a bug.  Not impacting user world, but still a bug is a bug.
> 
> I was arguing it as a bug even though ABI users cannot trigger the overflow,
> since damon_set_region_biggest_system_ram_default() is exposed to DAMON API
> callers, and I was thinking a future caller of the function could trigger the
> problem.  But I now realize the API function is safe from any call, since
> damon_find_biggest_system_ram() is avoiding the case, by setting 'end'
> parameter of walk_system_ram_res() as 'ULONG_MAX'.  Maybe it is not really
> appropriate to call it a bug.
> 
> That said, I now think this as a room to improve for the readability of the
> code.

So, I sent an RFC patch for this:
https://lore.kernel.org/20260305053918.83786-1-sj@kernel.org


Thanks,
SJ

[...]