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]
Date:   Tue, 9 Feb 2021 13:38:34 +0100
From:   Thomas Bogendoerfer <tsbogend@...ha.franken.de>
To:     Serge Semin <Sergey.Semin@...kalelectronics.ru>
Cc:     Paul Burton <paulburton@...nel.org>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        Serge Semin <fancer.lancer@...il.com>,
        Paul Cercueil <paul@...pouillou.net>,
        linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Revert "mips: Manually call fdt_init_reserved_mem()
 method"

On Mon, Feb 08, 2021 at 04:46:14PM +0300, Serge Semin wrote:
> 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(-)

applied to mips-next.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ