linux-kernel - Re: [PATCH v2 2/2] x86/of: add support for reserved memory defined by DT

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: <20250423140913.GA360030-robh@kernel.org>
Date: Wed, 23 Apr 2025 09:09:13 -0500
From: Rob Herring <robh@...nel.org>
To: Grzegorz Jaszczyk <jaszczyk@...omium.org>
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
	dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
	saravanak@...gle.com, dmaluka@...omium.org, bgrzesik@...gle.com,
	jaszczyk@...gle.com, ilpo.jarvinen@...ux.intel.com,
	usamaarif642@...il.com, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org, tnowicki@...gle.com,
	mazurekm@...gle.com, vineethrp@...gle.com
Subject: Re: [PATCH v2 2/2] x86/of: add support for reserved memory defined
 by DT

On Fri, Apr 18, 2025 at 12:47:18PM +0000, Grzegorz Jaszczyk wrote:
> From: Grzegorz Jaszczyk <jaszczyk@...gle.com>
> 
> The DT reserved-memory nodes can be present in DT as described in
> Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml.
> Similar to other architecture, which supports DT, there is a need to
> create reserved memory regions for such nodes.
> 
> Additionally, the x86 architecture builds its memory map based on E820
> description passed by bootloader and not on DT. Since x86 already has
> some DT support and allows booting with both ACPI and DT at the same
> time, let's register an arch specific hook which will validate if a
> reserved-memory region passed by DT is valid (covered by E820 reserved
> region entry).
> 
> Without this check, the reserved memory from DT could be successfully
> registered, even though such a region could conflict with e820
> description e.g. it could be described as E820_RAM and could be already
> used at early x86 boot stage for memblock initialization (which happens
> before DT parsing).

Sorry, I don't get how it conflicts. Wouldn't the E820_RAM be registered 
with memblock and memblock then handles the conflict (or should).

Rob