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

[SeongJae Park <sj@kernel.org>]

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.


Thanks,
SJ

[...]