linux-kernel - Re: [PATCH v3 3/7] mm: Implement for_each_valid_pfn() for CONFIG

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 for Android: free password hash cracker in your pocket

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

Message-ID: <72c09ecbe47d2868a87908c315888719e035f6fc.camel@infradead.org>
Date: Wed, 23 Apr 2025 13:05:14 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Mike Rapoport <rppt@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, "Sauerwein, David"
 <dssauerw@...zon.de>, Anshuman Khandual <anshuman.khandual@....com>, Ard
 Biesheuvel <ardb@...nel.org>, Catalin Marinas <catalin.marinas@....com>,
 David Hildenbrand <david@...hat.com>, Marc Zyngier <maz@...nel.org>, Mark
 Rutland <mark.rutland@....com>, Mike Rapoport <rppt@...ux.ibm.com>, Will
 Deacon <will@...nel.org>, kvmarm@...ts.cs.columbia.edu, 
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
 linux-mm@...ck.org, Ruihan Li <lrh2000@....edu.cn>
Subject: Re: [PATCH v3 3/7] mm: Implement for_each_valid_pfn() for
 CONFIG_SPARSEMEM

On Wed, 2025-04-23 at 14:11 +0300, Mike Rapoport wrote:
> 
> Looks like it's a leftover from one of the previous versions.
> 
> >   #ifndef for_each_valid_pfn
> > -#define for_each_valid_pfn(pfn, start_pfn,
> > end_pfn)			 \
> > -	for ((pfn) = max_t(unsigned long, (start_pfn),
> > ARCH_PFN_OFFSET); \
> > -	     (pfn) < min_t(unsigned long,
> > (end_pfn),			 \
> > -			   ARCH_PFN_OFFSET +
> > max_mapnr);		 \
> > -	     (pfn)++)
> > +#define for_each_valid_pfn(pfn, start_pfn,
> > end_pfn)			       \
> > +	for (pfn = max_t(unsigned long, start_pfn,
> > ARCH_PFN_OFFSET);	\
> > +	     pfn < min_t(unsigned long, end_pfn, ARCH_PFN_OFFSET +
> > max_mapnr); \
> > +			 pfn++)
> 
> And this one is probably a rebase artifact? 
> 
> With FLATMEM changes dropped

Oops, that was a result of me attempting to keep the SPARSEMEM thing in
two commits — the one you'd previously reviewed, and then the
'optimisation', as discussed.

And then giving up on it and just resetting to the previous 'optimised'
version in a single commit... and failing to realise that in doing so I
was also reverting the cleanups I'd done to the flatmem version.

Will fix that; thanks.

> This-revision-also-reviewed-by: Mike Rapoport (Microsoft) <rppt@...nel.org>


Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)