linux-kernel - Re: [tip: x86/urgent] x86/e820: Discard high memory that can't be addressed by 32-bit systems

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: <Z_9hmdMTP3wpB3Cc@gmail.com>
Date: Wed, 16 Apr 2025 09:51:53 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Mike Rapoport <rppt@...nel.org>, linux-kernel@...r.kernel.org,
	linux-tip-commits@...r.kernel.org, Arnd Bergmann <arnd@...nel.org>,
	Andy Shevchenko <andy@...nel.org>, Arnd Bergmann <arnd@...db.de>,
	Davide Ciminaghi <ciminaghi@...dd.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Matthew Wilcox <willy@...radead.org>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Sean Christopherson <seanjc@...gle.com>, kvm@...r.kernel.org,
	x86@...nel.org
Subject: Re: [tip: x86/urgent] x86/e820: Discard high memory that can't be
 addressed by 32-bit systems


* Ingo Molnar <mingo@...nel.org> wrote:

> 
> * Dave Hansen <dave.hansen@...el.com> wrote:
> 
> > On 4/15/25 00:18, Mike Rapoport wrote:
> > >> How about we reuse 'MAX_NONPAE_PFN' like this:
> > >>
> > >> 	if (IS_ENABLED(CONFIG_X86_32))
> > >> 		memblock_remove(PFN_PHYS(MAX_NONPAE_PFN), -1);
> > >>
> > >> Would that make the connection more obvious?
> > > Yes, that's better. Here's the updated patch:
> > 
> > Looks, great. Thanks for the update and the quick turnaround on the
> > first one after the bug report!
> > 
> > Tested-by: Dave Hansen <dave.hansen@...el.com>
> > Acked-by: Dave Hansen <dave.hansen@...el.com>
> 
> I've amended the fix in tip:x86/urgent accordingly and added your tags, 
> thanks!

So I had to apply the fix below as well, due to this build failure on 
x86-defconfig:

  arch/x86/kernel/e820.c:1307:42: error: ‘MAX_NONPAE_PFN’ undeclared (first use in this function); did you mean ‘MAX_DMA_PFN’?

IS_ENABLED(CONFIG_X86_32) can only be used when the code is 
syntactically correct on !CONFIG_X86_32 kernels too - which it wasn't.

So I went for the straightforward #ifdef block instead.

Thanks,

	Ingo

===========>
 arch/x86/kernel/e820.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index de6238886cb2..c984be8ee060 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1299,13 +1299,14 @@ void __init e820__memblock_setup(void)
 		memblock_add(entry->addr, entry->size);
 	}
 
+#ifdef CONFIG_X86_32
 	/*
 	 * Discard memory above 4GB because 32-bit systems are limited to 4GB
 	 * of memory even with HIGHMEM.
 	 */
-	if (IS_ENABLED(CONFIG_X86_32))
-		memblock_remove(PFN_PHYS(MAX_NONPAE_PFN), -1);
+	memblock_remove(PFN_PHYS(MAX_NONPAE_PFN), -1);
+#endif
 
 	/* Throw away partial pages: */
 	memblock_trim_memory(PAGE_SIZE);