linux-kernel - Re: [PATCH 07/46] Loongarch: reserved_mem: Implement the new processing order for reserved memory

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: <20240131152709.GA1272666-robh@kernel.org>
Date: Wed, 31 Jan 2024 09:27:09 -0600
From: Rob Herring <robh@...nel.org>
To: Oreoluwa Babatunde <quic_obabatun@...cinc.com>
Cc: catalin.marinas@....com, will@...nel.org, frowand.list@...il.com,
	vgupta@...nel.org, arnd@...db.de, olof@...om.net, soc@...nel.org,
	guoren@...nel.org, monstr@...str.eu, palmer@...belt.com,
	aou@...s.berkeley.edu, dinguyen@...nel.org, chenhuacai@...nel.org,
	tsbogend@...ha.franken.de, jonas@...thpole.se,
	stefan.kristiansson@...nalahti.fi, shorne@...il.com,
	mpe@...erman.id.au, ysato@...rs.sourceforge.jp, dalias@...c.org,
	glaubitz@...sik.fu-berlin.de, richard@....at,
	anton.ivanov@...bridgegreys.com, johannes@...solutions.net,
	chris@...kel.net, jcmvbkbc@...il.com,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	kernel@...cinc.com
Subject: Re: [PATCH 07/46] Loongarch: reserved_mem: Implement the new
 processing order for reserved memory

On Fri, Jan 26, 2024 at 03:53:46PM -0800, Oreoluwa Babatunde wrote:
> Call early_fdt_scan_reserved_mem() in place of
> early_init_fdt_scan_reserved_mem() to carry out the first stage of the
> reserved memory processing only.
> 
> The early_fdt_scan_reserved_mem() function is used to scan through the
> DT and mark all the reserved memory regions as reserved or nomap as
> needed, as well as allocate the memory required by the
> dynamically-placed
> reserved memory regions.
> 
> The second stage of the reserved memory processing is done by
> fdt_init_reserved_mem(). This function is used to store the information
> of the statically-placed reserved memory nodes in the reserved_mem
> array as well as call the region specific initialization function on all
> the stored reserved memory regions.
> 
> The call to fdt_init_reserved_mem() is placed right after
> early_fdt_scan_reserved_mem() since memblock allocated memory should
> already be writable at this point.
> 
> Signed-off-by: Oreoluwa Babatunde <quic_obabatun@...cinc.com>
> ---
>  arch/loongarch/kernel/setup.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/loongarch/kernel/setup.c b/arch/loongarch/kernel/setup.c
> index edf2bba80130..72b164d3ace0 100644
> --- a/arch/loongarch/kernel/setup.c
> +++ b/arch/loongarch/kernel/setup.c
> @@ -30,6 +30,7 @@
>  #include <linux/dma-map-ops.h>
>  #include <linux/libfdt.h>
>  #include <linux/of_fdt.h>
> +#include <linux/of_reserved_mem.h>
>  #include <linux/of_address.h>
>  #include <linux/suspend.h>
>  #include <linux/swiotlb.h>
> @@ -390,8 +391,9 @@ static void __init arch_mem_init(char **cmdline_p)
>  
>  	check_kernel_sections_mem();
>  
> -	early_init_fdt_scan_reserved_mem();
> +	early_fdt_scan_reserved_mem();

Looking at the loongarch code, there's an existing problem with the 
order of init. This is done after unflattening and copying the DT. That 
means the kernel could freely allocate memory for the DT in a reserved 
region.

Rob