Re: RCU bug with v3.17-rc3 ?

Rabin Vincent
2014-10-09T20:41:01Z

On Thu, Oct 09, 2014 at 11:26:56AM -0500, Felipe Balbi wrote:
> alright, it's pretty deterministic however. Always on the same test, no
> matter which USB controller, no matter if backing store is RAM or MMC.
>
> Those two undefined instructions on the disassembly caught my attention,
> perhaps I'm facing a GCC bug ?

The undefined instructions are just ARM's BUG() implementation.

But did you see the question I asked you yesterday in your other thread?
http://www.spinics.net/lists/arm-kernel/msg368634.html

Here it is again:

What GCC version are you using?

4.8.1 and 4.8.2 are known to miscompile the ARM kernel and these
find_get_entry() crashes with 0xffffffff involved smell a lot like the
earlier reports from kernels build with those compilers:

https://lkml.org/lkml/2014/6/25/456
https://lkml.org/lkml/2014/6/30/375
https://lkml.org/lkml/2014/6/30/660
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
https://lkml.org/lkml/2014/5/9/330

Also, I didn't see any public email making a definitive link between GCC
PR 58854 that Nathan pointed out in https://lkml.org/lkml/2014/6/30/660
and the earlier find_get_entry() crashes, but I just built GCC 4.8.1 and
an ARM kernel with that, and the GCC bug is clearly seen in
radix_tree_lookup_slot() which returns the pointer which
find_get_entry() is dereferencing:

<radix_tree_lookup_slot>:
e1a0c00d mov ip, sp
e92dd800 push {fp, ip, lr, pc}
e24cb004 sub fp, ip, #4
e24dd008 sub sp, sp, #8
e3a02000 mov r2, #0
e24b3010 sub r3, fp, #16
ebffffc5 bl c0176ab8 <__radix_tree_lookup>
e24bd00c sub sp, fp, #12 <--- sp moved up
e3500000 cmp r0, #0
151b0010 ldrne r0, [fp, #-16] <--- load from under sp
e89da800 ldm sp, {fp, sp, pc}

Please check your compiler to make sure it's not the same problem.