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-next>] [day] [month] [year] [list]
Date:   Mon, 8 Feb 2021 16:46:14 +0300
From:   Serge Semin <Sergey.Semin@...kalelectronics.ru>
To:     Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Paul Burton <paulburton@...nel.org>,
        Jiaxun Yang <jiaxun.yang@...goat.com>
CC:     Serge Semin <Sergey.Semin@...kalelectronics.ru>,
        Serge Semin <fancer.lancer@...il.com>,
        Paul Cercueil <paul@...pouillou.net>,
        <linux-mips@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: [PATCH] Revert "mips: Manually call fdt_init_reserved_mem() method"

This reverts commit 3751cbda8f223549d7ea28803cbec8ac87e43ed2.

Originally the patch was created to fix the reserved-memory DT-node
parsing failure on the early stages of the platform memory initialization.
That happened due to the two early memory allocators utilization that
time: bootmem and memblock. At first the platform-specific memory mapping
array was initialized. Then the early_init_fdt_scan_reserved_mem() was
called, which couldn't fully parse the "reserved-memory" DT-node since
neither memblock nor bootmem allocators hadn't been initialized at that
stage, so the fdt_init_reserved_mem() method failed on the memory
allocation calls. Only after that the platform-specific memory mapping
were used to create proper bootmem and memblock structures and let the
early memory allocations work.  That's why we had to call the
fdt_init_reserved_mem() method one more time to retry the initialization
of the features like CMA.

The necessity to have that fix was disappeared after the full memblock
support had been added to the MIPS kernel and all plat_mem_setup() had
been fixed to add the memory regions right into the memblock memory pool.
Let's revert that patch then especially after having Paul reported that
the second fdt_init_reserved_mem() call causes the reserved memory pool
being created twice bigger than implied.

Fixes: a94e4f24ec83 ("MIPS: init: Drop boot_mem_map")
Reported-by: Paul Cercueil <paul@...pouillou.net>
Signed-off-by: Serge Semin <Sergey.Semin@...kalelectronics.ru>
---
 arch/mips/kernel/setup.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 101812960ca0..a60ecd6db0c3 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -27,7 +27,6 @@
 #include <linux/dma-map-ops.h>
 #include <linux/decompress/generic.h>
 #include <linux/of_fdt.h>
-#include <linux/of_reserved_mem.h>
 #include <linux/dmi.h>
 
 #include <asm/addrspace.h>
@@ -686,8 +685,6 @@ static void __init arch_mem_init(char **cmdline_p)
 	memblock_reserve(__pa_symbol(&__nosave_begin),
 		__pa_symbol(&__nosave_end) - __pa_symbol(&__nosave_begin));
 
-	fdt_init_reserved_mem();
-
 	early_memtest(PFN_PHYS(ARCH_PFN_OFFSET), PFN_PHYS(max_low_pfn));
 }
 
-- 
2.29.2

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ