linux-kernel - Re: [RFC PATCH -next 00/16] mm/damon: support ARM32 with LPAE

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: <20250814160429.67476-1-sj@kernel.org>
Date: Thu, 14 Aug 2025 09:04:29 -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: [RFC PATCH -next 00/16] mm/damon: support ARM32 with LPAE

On Thu, 14 Aug 2025 22:07:12 +0800 Quanmin Yan <yanquanmin1@...wei.com> wrote:

> 
> 在 2025/8/14 8:57, SeongJae Park 写道:
> > On Wed, 13 Aug 2025 10:25:44 -0700 SeongJae Park <sj@...nel.org> wrote:
> >
> >> Hello Quanmin,
> >>
> >> On Wed, 13 Aug 2025 13:06:50 +0800 Quanmin Yan <yanquanmin1@...wei.com> wrote:
> >>
> >>> Previously, DAMON's physical address space monitoring only supported
> >>> memory ranges below 4GB on LPAE-enabled systems. This was due to
> >>> the use of 'unsigned long' in 'struct damon_addr_range', which is
> >>> 32-bit on ARM32 even with LPAE enabled.
> >>>
> >>> Implements DAMON compatibility for ARM32 with LPAE enabled.
> >> Thank you for working on this, Quanmin!
> >>
> >>> Patches 01/16 through 10/16 are from the mailing list[1], add a new core
> >>> layer parameter called 'addr_unit'. Operations set layer can translate a
> >>> core layer address to the real address by multiplying the parameter value
> >>> to the core layer address.
> >>>
> >>> Patches 11/16 through 14/16 extend and complement patches 01~10, addressing
> >>> various issues introduced by the addr_unit implementation.
> >>>
> >>> Patches 15/16 and 16/16 complete native DAMON support for 32-bit systems.
> >> Overall, looks good to me.  I have a few change requests including below major
> >> ones, though.
> >>
> >> First, let's squash patches for fixing problems made with patches 1-10 into
> >> patches 1-10.  If you don't mind, I will post RFC v2 of those so that you can
> >> pick into your series.
> >>
> >> Second, let's keep DAMOS stats in 'unsigned long' type.  This require fixups of
> >> patches 1-10.  If you don't mind, I will also do this in RFC v2 of those.
> > Instead of posting completely new RFC v2 of the ten patches, I think posting
> > fixup patches as replies to this thread might be a better approach.  I will
> > make fixups first, see what looks easier for working together with you, and
> > either post entirely new version of the patch series, or send individual fixups
> > as replies to each patch of this thread.
> >
> > And one more questions.  What is the baseline if this series?  I cannot simply
> > apply these patches on mm-unstable or mm-new.  It would be nice if you could
> > share a git tree having these patches fully applied, since 'cherry-pick' is
> > easier than 'am' for me.
> 
> Hi SJ,
> 
> Thank you for your detailed suggestions on the patch series. Please allow me
> some time to thoroughly review each of your recommendations.

No worry, please take your time :)

> I haven’t responded
> to every point immediately because I’d like to first attempt updating the patches
> accordingly. If I encounter any questions or issues during the process, I’ll promptly
> reach out to discuss them with you, very appreciate your patience and guidance.

Sounds good.

> 
> By the way, this patch series is based on linux-next(commit:2674d1eadaa2).

Thank you for sharing this.  From the next time, please use mm-new[1] as a
baseline for DAMON patches if there is no reason to not do so.

[1] https://origin.kernel.org/doc/html/latest/mm/damon/maintainer-profile.html#scm-trees


Thanks,
SJ

[...]