linux-kernel - Re: [RFC PATCH] mm/damon: add full LPAE support for memory monitoring above 4GB

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <a5c871c8-dc52-4245-8513-94ccc2b46c94@huawei.com>
Date: Fri, 25 Jul 2025 11:15:22 +0800
From: zuoze <zuoze1@...wei.com>
To: SeongJae Park <sj@...nel.org>
CC: <akpm@...ux-foundation.org>, <damon@...ts.linux.dev>,
	<linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
	<wangkefeng.wang@...wei.com>, <yanquanmin1@...wei.com>
Subject: Re: [RFC PATCH] mm/damon: add full LPAE support for memory monitoring
 above 4GB

在 2025/4/23 1:43, SeongJae Park 写道:
> On Tue, 22 Apr 2025 19:50:11 +0800 zuoze <zuoze1@...wei.com> wrote:
> 
> [...]
>> Thanks for the patches - I’ve noted the RFC series and user-space
>> updates. Apologies for the delay; I’ll prioritize reviewing these soon
>> to verify they meet the intended tracking goals. Appreciate your
>> patience.
> 
> No worry.  Please take your time and let me know if there is anything I can
> help.
> 
> I think we can improve the user-space tool support better for usability.  For
> example, it could find LPAE case, set addr_unit parameter, and convert
> user-input and output address ranges on its own.  But hopefully the current
> support allows simple tests of the kernel side change, and we could do such
> improvement after the kernel side change is made.
> 
> 

Hi SJ,

Apologies for the delayed response. We've verified your patch in our
environment and confirmed it supports LPAE address monitoring. However,
we observed some anomalies in the reclaim functionality. During code
review, we identified a few issues:

The semantic meaning of damon_region changed after addr_unit was
introduced. The units in damon_addr_range may no longer represent bytes
directly.

The size returned by damon_sz_region() now requires multiplication by
addr_unit to get the actual byte count.

Heavy usage of damon_sz_region() and DAMON_MIN_REGION likely requires
addr_unit-aware adjustments throughout the codebase. While this approach
works, it would involve considerable changes. What's your perspective on
how we should proceed?

Best regards,
Ze Zuo

> Thanks,
> SJ
> 
> [...]
>