linux-kernel - Re: Qemu crashes in -next due to 'of: remove *phandle properties from expanded device tree'

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]

Date:   Wed, 14 Jun 2017 14:31:58 -0700
From:   Frank Rowand <frowand.list@...il.com>
To:     Guenter Roeck <linux@...ck-us.net>,
        Frank Rowand <frank.rowand@...y.com>
Cc:     linux-kernel@...r.kernel.org, Rob Herring <robh@...nel.org>
Subject: Re: Qemu crashes in -next due to 'of: remove *phandle properties from
 expanded device tree'

Hi Guenter,

Thanks for reporting this.


On 06/14/17 12:26, Guenter Roeck wrote:
> Hi Frank,
> 
> your commit 'of: remove *phandle properties from expanded device tree' in
> -next causes several of my ppc qemu tests to crash. Looking into qemu, it
> sets "linux,phandle" properties for the mpic and for other devices.
> 
> The crashes are along the line of
> 
> ------------[ cut here ]------------
> kernel BUG at arch/powerpc/platforms/85xx/corenet_generic.c:50!
> Oops: Exception in kernel mode, sig: 5 [#1]
> SMP NR_CPUS=32 
> NUMA 
> CoreNet Generic
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.12.0-rc5-next-20170614 #1
> task: c000000000ad8cc0 task.stack: c000000000bec000
> NIP: c000000000a8ca7c LR: c000000000a8ca6c CTR: c000000000a8ca20
> REGS: c000000000befb90 TRAP: 0700   Not tainted  (4.12.0-rc5-next-20170614)
> MSR: 0000000080021000 <CE,ME>
>   CR: 22000042  XER: 00000000
>   SOFTE: 0 
>   GPR00: c000000000a8ca6c c000000000befe10 c000000000befa00 0000000000000000 
>   GPR04: 0000000000000000 c000000000ac8458 c000000000ac8438 c000000000830658 
>   GPR08: 0000000000000001 0000000000000001 0000000000000000 0000000000009531 
>   GPR12: 0000000022000022 c00000003fff1000 0000000000000000 0000000000000000 
>   GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 
>   GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 
>   GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 
>   GPR28: c000000000000300 c00000003fff2cc0 c000000000ac06e0 c000000000ac06e0 
>   NIP [c000000000a8ca7c] .corenet_gen_pic_init+0x5c/0x90
>   LR [c000000000a8ca6c] .corenet_gen_pic_init+0x4c/0x90
>   Call Trace:
>   [c000000000befe10] [c000000000a8ca6c] .corenet_gen_pic_init+0x4c/0x90
>   (unreliable)
>   [c000000000befe80] [c000000000a832f8] .init_IRQ+0x34/0x4c
>   [c000000000befef0] [c000000000a7fc88] .start_kernel+0x2fc/0x500
>   [c000000000beff90] [c000000000000554] start_here_common+0x1c/0x48
>   Instruction dump:
>   e8aa0068 39088268 39407002 38600000 7fa54800 39205002 7caa4f9e 4bffe9e9 
>   60000000 2c230000 7d200026 55291ffe <0b090000> 4bfff335 60000000 3ca2ffdd 
>   random: 0x600000003d220004 get_random_bytes called with crng_init=0
>   ---[ end trace 0000000000000000 ]---
> 
> and are caused by the kernel not finding the mpic node anymore.
> 
> Any idea how to solve the problem ?

The BUG() is triggered if mpic_alloc() returns NULL.

I looked through mpic_alloc(), and the functions that it calls, and nothing
is jumping out as being related to phandles.

Can you add some printks to mpic_alloc() to determine what problem is
causing it to return NULL?

Can you also include the console messages before the "[ cut here ]" line?

-Frank

> 
> Bisect log is attached.
> 
> Thanks,
> Guenter

< snip >