linux-kernel - Re: [PATCH 2/2] mm/damon/reclaim: support addr_unit for DAMON

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20250911022005.52673-1-sj@kernel.org>
Date: Wed, 10 Sep 2025 19:20:05 -0700
From: SeongJae Park <sj@...nel.org>
To: Quanmin Yan <yanquanmin1@...wei.com>
Cc: SeongJae Park <sj@...nel.org>,
	akpm@...ux-foundation.org,
	damon@...ts.linux.dev,
	linux-kernel@...r.kernel.org,
	linux-mm@...ck.org,
	wangkefeng.wang@...wei.com,
	zuoze1@...wei.com
Subject: Re: [PATCH 2/2] mm/damon/reclaim: support addr_unit for DAMON_RECLAIM

On Wed, 10 Sep 2025 19:32:21 +0800 Quanmin Yan <yanquanmin1@...wei.com> wrote:

> Implement a sysfs file to expose addr_unit for DAMON_RECLAIM
> users. During parameter application, use the configured
> addr_unit parameter to perform the necessary initialization.
> Similar to the core layer, prevent setting addr_unit to zero.
> 
> It is worth noting that when monitor_region_start and
> monitor_region_end are unset (i.e., 0), their values will
> later be set to biggest_system_ram. At that point, addr_unit
> may not be the default value 1. Although we could divide the
> biggest_system_ram value by addr_unit, changing addr_unit
> without setting monitor_region_start/end should be considered
> a user misoperation. And biggest_system_ram is only within
> the 0~ULONG_MAX range, system can clearly work correctly with
> addr_unit=1. Therefore, if monitor_region_start/end are unset,
> always silently reset addr_unit to 1.

Again, sounds fair to me.  Also this kind of information is helpful at
reviewing.  Thank you Quanmin :)

> 
> Signed-off-by: Quanmin Yan <yanquanmin1@...wei.com>

Reviewed-by: SeongJae Park <sj@...nel.org>


Thanks,
SJ

[...]