linux-kernel - Re: nios2 crash/hang in mainline due to 'lib: update LZ4 compressor module'

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: <20170309144340.GH27998@distanz.ch>
Date:   Thu, 9 Mar 2017 15:43:40 +0100
From:   Tobias Klauser <tklauser@...tanz.ch>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Sven Schmidt <4sschmid@...ormatik.uni-hamburg.de>,
        Sandra Loosemore <sandra@...esourcery.com>,
        Arnd Bergmann <arnd@...db.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, Ley Foon Tan <lftan@...era.com>,
        nios2-dev@...ts.rocketboards.org
Subject: Re: nios2 crash/hang in mainline due to 'lib: update LZ4 compressor
 module'

On 2017-03-09 at 14:20:51 +0100, Guenter Roeck <linux@...ck-us.net> wrote:
> On 03/07/2017 04:46 AM, Tobias Klauser wrote:
> [ ... ]
> 
> >
> >Linux version 4.11.0-rc1-dirty (tobiask@...s08) (gcc version 7.0.1 20170226 (experimental) (GCC) ) #46 Tue Mar 7 13:40:53 CET 2017
> >bootconsole [early0] enabled
> >Early console on uart16650 initialized at 0xf8001600
> >OF: fdt: Error -11 processing FDT
> >Kernel panic - not syncing: setup_cpuinfo: No CPU found in devicetree!
> >
> >---[ end Kernel panic - not syncing: setup_cpuinfo: No CPU found in devicetree!
> >
> >Looks like the in-memory device tree somehow gets corrupted. Not sure
> >yet why and how this is linked to the Kconfig options selected but at
> >least we now have a possibility to use debug messages earlier on.
> >
> 
> I think I found the problem. In unflatten_and_copy_device_tree(), with added
> debug information:
> 
> OF: fdt: initial_boot_params=c861e400, dt=c861f000 size=28874 (0x70ca)
> 
> ... and then initial_boot_params is copied to dt, which results in corrupted
> fdt since the memory overlaps. Looks like the initial_boot_params memory
> is not reserved and (re-)allocated by early_init_dt_alloc_memory_arch().

Thanks for the analysis. That certainly explains the issue. The
following patch solves the issue for me. Though I'm not entirely sure if
it is correct and that is all that is needed. Do we need to retain the
memory for initial_boot_params after bootmem is freed?

diff --git a/arch/nios2/kernel/prom.c b/arch/nios2/kernel/prom.c
index 099f5ce1f3cb..6869fe03f3ff 100644
--- a/arch/nios2/kernel/prom.c
+++ b/arch/nios2/kernel/prom.c
@@ -48,6 +48,13 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
 	return alloc_bootmem_align(size, align);
 }
 
+int __init early_init_dt_reserve_memory_arch(phys_addr_t base,
+					phys_addr_t size, bool nomap)
+{
+	reserve_bootmem(base, size, BOOTMEM_DEFAULT);
+	return 0;
+}
+
 void __init early_init_devtree(void *params)
 {
 	__be32 *dtb = (u32 *)__dtb_start;
diff --git a/arch/nios2/kernel/setup.c b/arch/nios2/kernel/setup.c
index 6e57ffa5db27..6044d9be28b4 100644
--- a/arch/nios2/kernel/setup.c
+++ b/arch/nios2/kernel/setup.c
@@ -201,6 +201,9 @@ void __init setup_arch(char **cmdline_p)
 	}
 #endif /* CONFIG_BLK_DEV_INITRD */
 
+	early_init_fdt_reserve_self();
+	early_init_fdt_scan_reserved_mem();
+
 	unflatten_and_copy_device_tree();
 
 	setup_cpuinfo();