kernel miscompilation with gcc 4.8 for ARMv5

kernel miscompilation with gcc 4.8 for ARMv5

[Enrico Scholz]

Hi,

is it expected that recent gcc 4.8[1] compiles the kernel correctly?
Kernels for ARMv5 platforms (PXA168 -> 3.4.52, MX28 -> 3.8.13) fail here
100% at early boot with

[    0.404750] Unable to handle kernel paging request at virtual address 00210020
[    0.412468] pgd = c0004000
[    0.415187] [00210020] *pgd=00000000
[    0.418812] Internal error: Oops: 5 [#1] PREEMPT ARM
[    0.423781] CPU: 0    Not tainted  (3.8.13.ipan4 #1)
[    0.428781] PC is at kmem_cache_alloc+0x44/0xcc
[    0.433375] LR is at con_insert_unipair+0xa4/0xf0
[    0.438093] pc : [<c00a6d7c>]    lr : [<c02dc654>]    psr: 20000053

(this is a similar error as described in [2]).  Enabling heavy memory
debugging shows

[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xc8800000 - 0xff000000   ( 872 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0436000   (4280 kB)
[    0.000000]       .init : 0xc0436000 - 0xc046a000   ( 208 kB)
[    0.000000]       .data : 0xc046a000 - 0xc049bff8   ( 200 kB)
[    0.000000]        .bss : 0xc049c01c - 0xc0511680   ( 470 kB)
[    0.000000] =============================================================================
[    0.000000] BUG kmem_cache_node (Not tainted): Redzone overwritten
[    0.000000] -----------------------------------------------------------------------------
[    0.000000] 
[    0.000000] INFO: 0xc78010fc-0xc78010ff. First byte 0x5a instead of 0xbb
[    0.000000] INFO: Slab 0xc0620024 objects=18 used=18 fp=0x  (null) flags=0x0080
[    0.000000] INFO: Object 0xc78010e0 @offset=224 fp=0xc78011c0
[    0.000000] 
[    0.000000] Bytes b4 c78010d0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
[    0.000000] Object c78010e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[    0.000000] Object c78010f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 5a              kkkkkkkkkkkZ
[    0.000000] Redzone c78010fc: 5a 5a 5a 5a                                      ZZZZ
[    0.000000] Padding c78011a4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
[    0.000000] Padding c78011b4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a              ZZZZZZZZZZZZ
[    0.000000] Backtrace: 

for the 3.4.52 kernel.  Compiling mm/slub.o with -O1 fixes *these*
problems but there happen other crashes later.


A kernel compiled for an ARMv7 platform (OMAP4, kernel 3.4.43) seems to
work (although there might be enabled other kernel options).


Are these problems resp. fixes known?



Enrico

Footnotes: 
[1]  from 4f5009dcbbeb27bdf5dcaebb3b457fecef410ebe

[2]  https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1178847

Re: kernel miscompilation with gcc 4.8 for ARMv5

[Enrico Scholz]

Enrico Scholz
<enrico.scholz-wttK6gPy29v+Hn7q9Vec/7NAH6kLmebB@public.gmane.org>
writes:

> is it expected that recent gcc 4.8[1] compiles the kernel correctly?
> Kernels for ARMv5 platforms (PXA168 -> 3.4.52, MX28 -> 3.8.13) fail here
> 100% at early boot with

Applying two upstream kernel commits
455bd4c430b0c0a361f38e8658a0d6cb469942b5 (ARM: 7668/1: fix
memset-related crashes caused by recent GCC (4.7.2) optimizations) and
418df63adac56841ef6b0f1fcf435bc64d4ed177 (ARM: 7670/1: fix the memset
fix) seem to fix the problem for me.



Enrico

Re: kernel miscompilation with gcc 4.8 for ARMv5

[Mike Looijmans]

On 07/10/2013 02:34 PM, Enrico Scholz wrote:
> Enrico Scholz
> <enrico.scholz-wttK6gPy29v+Hn7q9Vec/7NAH6kLmebB@public.gmane.org>
> writes:
>
>> is it expected that recent gcc 4.8[1] compiles the kernel correctly?
>> Kernels for ARMv5 platforms (PXA168 -> 3.4.52, MX28 -> 3.8.13) fail here
>> 100% at early boot with
>
> Applying two upstream kernel commits
> 455bd4c430b0c0a361f38e8658a0d6cb469942b5 (ARM: 7668/1: fix
> memset-related crashes caused by recent GCC (4.7.2) optimizations) and
> 418df63adac56841ef6b0f1fcf435bc64d4ed177 (ARM: 7670/1: fix the memset
> fix) seem to fix the problem for me.
>

I encountered a compilation problem for MIPS kernels (version 3.3 and 
below) with the new GCC compiler:


  arch/mips/mm/page.c:89:6: error: 'clear_page' alias in between 
function and variable is not supported
void clear_page(void *page) __attribute__((alias("clear_page_array")));
        ^
arch/mips/mm/page.c:84:12: error: 'clear_page_array' aliased declaration 
[-Werror]
static u32 clear_page_array[0x120 / 4];
              ^
arch/mips/mm/page.c:108:6: error: 'copy_page' alias in between function 
and variable is not supported
void copy_page(void *to, void *from) 
__attribute__((alias("copy_page_array")));
       ^
arch/mips/mm/page.c:102:12: error: 'copy_page_array' aliased declaration 
[-Werror]
static u32 copy_page_array[0x540 / 4];


So I'll probably have to go and look for backports to apply here. Anyone 
happen to come across this one already?
(Looking in the git history for that file suggests applying 
c022630633624a75b3b58f43dd3c6cc896a56cff from upstream)

A 3.8 kernel is running just fine with gcc 4.8.

Re: kernel miscompilation with gcc 4.8 for ARMv5

[Mark Hatle]

On 7/10/13 8:15 AM, Mike Looijmans wrote:
> On 07/10/2013 02:34 PM, Enrico Scholz wrote:
>> Enrico Scholz
>> <enrico.scholz-wttK6gPy29v+Hn7q9Vec/7NAH6kLmebB@public.gmane.org>
>> writes:
>>
>>> is it expected that recent gcc 4.8[1] compiles the kernel correctly?
>>> Kernels for ARMv5 platforms (PXA168 -> 3.4.52, MX28 -> 3.8.13) fail here
>>> 100% at early boot with
>>
>> Applying two upstream kernel commits
>> 455bd4c430b0c0a361f38e8658a0d6cb469942b5 (ARM: 7668/1: fix
>> memset-related crashes caused by recent GCC (4.7.2) optimizations) and
>> 418df63adac56841ef6b0f1fcf435bc64d4ed177 (ARM: 7670/1: fix the memset
>> fix) seem to fix the problem for me.
>>
>
> I encountered a compilation problem for MIPS kernels (version 3.3 and
> below) with the new GCC compiler:
>
>
>    arch/mips/mm/page.c:89:6: error: 'clear_page' alias in between
> function and variable is not supported
> void clear_page(void *page) __attribute__((alias("clear_page_array")));
>          ^
> arch/mips/mm/page.c:84:12: error: 'clear_page_array' aliased declaration
> [-Werror]
> static u32 clear_page_array[0x120 / 4];
>                ^
> arch/mips/mm/page.c:108:6: error: 'copy_page' alias in between function
> and variable is not supported
> void copy_page(void *to, void *from)
> __attribute__((alias("copy_page_array")));
>         ^
> arch/mips/mm/page.c:102:12: error: 'copy_page_array' aliased declaration
> [-Werror]
> static u32 copy_page_array[0x540 / 4];
>
>
> So I'll probably have to go and look for backports to apply here. Anyone
> happen to come across this one already?
> (Looking in the git history for that file suggests applying
> c022630633624a75b3b58f43dd3c6cc896a56cff from upstream)
>
> A 3.8 kernel is running just fine with gcc 4.8.

The following commit fixed the issue in 3.4.  I assume it'll work in other versions.

kernel.org commit: c022630633624a75b3b58f43dd3c6cc896a56cff

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c022630633624a75b3b58f43dd3c6cc896a56cff

> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

Re: kernel miscompilation with gcc 4.8 for ARMv5

[Bruce Ashfield]

On Wed, Jul 10, 2013 at 9:34 AM, Enrico Scholz
<enrico.scholz@sigma-chemnitz.de> wrote:
> Enrico Scholz
> <enrico.scholz-wttK6gPy29v+Hn7q9Vec/7NAH6kLmebB@public.gmane.org>
> writes:
>
>> is it expected that recent gcc 4.8[1] compiles the kernel correctly?
>> Kernels for ARMv5 platforms (PXA168 -> 3.4.52, MX28 -> 3.8.13) fail here
>> 100% at early boot with
>
> Applying two upstream kernel commits
> 455bd4c430b0c0a361f38e8658a0d6cb469942b5 (ARM: 7668/1: fix
> memset-related crashes caused by recent GCC (4.7.2) optimizations) and
> 418df63adac56841ef6b0f1fcf435bc64d4ed177 (ARM: 7670/1: fix the memset
> fix) seem to fix the problem for me.

Correct. Those are the same commits you'll see on linux-yocto-3.8, we've been
soaking them for a while. I was waiting for LTSI and -stable to pick
up the changes
before updating linux-yocto-3.4, but that hasn't happened yet.

If you are using linux-yocto-3.4 and can confirm that it boots for you
with those patches,
I can stage them in my tree while I wait for them to loop around.

Cheers,

Bruce

>
>
>
> Enrico
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: kernel miscompilation with gcc 4.8 for ARMv5

[Enrico Scholz]

Bruce Ashfield <bruce.ashfield-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
writes:

>> Applying two upstream kernel commits
>> 455bd4c430b0c0a361f38e8658a0d6cb469942b5 (ARM: 7668/1: fix
>> memset-related crashes caused by recent GCC (4.7.2) optimizations) and
>> 418df63adac56841ef6b0f1fcf435bc64d4ed177 (ARM: 7670/1: fix the memset
>> fix) seem to fix the problem for me.
>
> Correct. Those are the same commits you'll see on linux-yocto-3.8,
> we've been soaking them for a while. I was waiting for LTSI and -stable
> to pick up the changes before updating linux-yocto-3.4, but that hasn't
> happened yet.
>
> If you are using linux-yocto-3.4 and can confirm that it boots for you
> with those patches,

Sorry, I am using a more or less vanilla 3.4 kernel.  Patches fix
the problem there (device boots) and (after knowing about them) the
problematic code is easy to spot:

$ arm-linux-gnueabi-objdump  -d mm/slub.o

000014c4 <init_object>:
    ...
    14fc:       e1a00001        mov     r0, r1
    1500:       e3a0106b        mov     r1, #107        ; 0x6b
    1504:       ebfffffe        bl      0 <memset>
    1508:       e1a03000        mov     r3, r0          <<<<<<<
    150c:       e5942010        ldr     r2, [r4, #16]
    1510:       e3e0105a        mvn     r1, #90 ; 0x5a
    1514:       e0832002        add     r2, r3, r2
    1518:       e5421001        strb    r1, [r2, #-1]

With unpatched memset, 'r0' points to end of buffer.


Enrico

Re: kernel miscompilation with gcc 4.8 for ARMv5

[Bruce Ashfield]

On Wed, Jul 10, 2013 at 11:30 AM, Enrico Scholz
<enrico.scholz@sigma-chemnitz.de> wrote:
> Bruce Ashfield <bruce.ashfield-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> writes:
>
>>> Applying two upstream kernel commits
>>> 455bd4c430b0c0a361f38e8658a0d6cb469942b5 (ARM: 7668/1: fix
>>> memset-related crashes caused by recent GCC (4.7.2) optimizations) and
>>> 418df63adac56841ef6b0f1fcf435bc64d4ed177 (ARM: 7670/1: fix the memset
>>> fix) seem to fix the problem for me.
>>
>> Correct. Those are the same commits you'll see on linux-yocto-3.8,
>> we've been soaking them for a while. I was waiting for LTSI and -stable
>> to pick up the changes before updating linux-yocto-3.4, but that hasn't
>> happened yet.
>>
>> If you are using linux-yocto-3.4 and can confirm that it boots for you
>> with those patches,
>
> Sorry, I am using a more or less vanilla 3.4 kernel.  Patches fix
> the problem there (device boots) and (after knowing about them) the
> problematic code is easy to spot:

No worries. I can spot the fix, since we already did this for the 3.8 kernel. I
was just no where near my targets at the moment .. and if I had an independent
report that things boot, I'd go ahead and push my 3.8 fixes (ported to
3.4) .. which
I may do anyway, since I can drop them when they cycle through -stable and
LTSI.

Cheers,

Bruce

>
> $ arm-linux-gnueabi-objdump  -d mm/slub.o
>
> 000014c4 <init_object>:
>     ...
>     14fc:       e1a00001        mov     r0, r1
>     1500:       e3a0106b        mov     r1, #107        ; 0x6b
>     1504:       ebfffffe        bl      0 <memset>
>     1508:       e1a03000        mov     r3, r0          <<<<<<<
>     150c:       e5942010        ldr     r2, [r4, #16]
>     1510:       e3e0105a        mvn     r1, #90 ; 0x5a
>     1514:       e0832002        add     r2, r3, r2
>     1518:       e5421001        strb    r1, [r2, #-1]
>
> With unpatched memset, 'r0' points to end of buffer.
>
>
> Enrico
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: kernel miscompilation with gcc 4.8 for ARMv5

[Mike Looijmans]

On 07/10/2013 03:25 PM, Mark Hatle wrote:
> On 7/10/13 8:15 AM, Mike Looijmans wrote:
>> On 07/10/2013 02:34 PM, Enrico Scholz wrote:
>>> Enrico Scholz
>>> <enrico.scholz-wttK6gPy29v+Hn7q9Vec/7NAH6kLmebB@public.gmane.org>
>>> writes:
>>>
>>>> is it expected that recent gcc 4.8[1] compiles the kernel correctly?
>>>> Kernels for ARMv5 platforms (PXA168 -> 3.4.52, MX28 -> 3.8.13) fail
>>>> here
>>>> 100% at early boot with
>>>
>>> Applying two upstream kernel commits
>>> 455bd4c430b0c0a361f38e8658a0d6cb469942b5 (ARM: 7668/1: fix
>>> memset-related crashes caused by recent GCC (4.7.2) optimizations) and
>>> 418df63adac56841ef6b0f1fcf435bc64d4ed177 (ARM: 7670/1: fix the memset
>>> fix) seem to fix the problem for me.
>>>
>>
>> I encountered a compilation problem for MIPS kernels (version 3.3 and
>> below) with the new GCC compiler:
>>
>>
>>    arch/mips/mm/page.c:89:6: error: 'clear_page' alias in between
>> function and variable is not supported
>> void clear_page(void *page) __attribute__((alias("clear_page_array")));
>>          ^
>> arch/mips/mm/page.c:84:12: error: 'clear_page_array' aliased declaration
>> [-Werror]
>> static u32 clear_page_array[0x120 / 4];
>>                ^
>> arch/mips/mm/page.c:108:6: error: 'copy_page' alias in between function
>> and variable is not supported
>> void copy_page(void *to, void *from)
>> __attribute__((alias("copy_page_array")));
>>         ^
>> arch/mips/mm/page.c:102:12: error: 'copy_page_array' aliased declaration
>> [-Werror]
>> static u32 copy_page_array[0x540 / 4];
>>
>>
>> So I'll probably have to go and look for backports to apply here. Anyone
>> happen to come across this one already?
>> (Looking in the git history for that file suggests applying
>> c022630633624a75b3b58f43dd3c6cc896a56cff from upstream)
>>
>> A 3.8 kernel is running just fine with gcc 4.8.
>
> The following commit fixed the issue in 3.4.  I assume it'll work in
> other versions.
>
> kernel.org commit: c022630633624a75b3b58f43dd3c6cc896a56cff
>
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c022630633624a75b3b58f43dd3c6cc896a56cff

Indeed, patching that into the kernels fixed it.

Mike.

Re: kernel miscompilation with gcc 4.8 for ARMv5

[Bruce Ashfield]

On Wed, Jul 10, 2013 at 9:57 AM, Bruce Ashfield
<bruce.ashfield@gmail.com> wrote:
> On Wed, Jul 10, 2013 at 9:34 AM, Enrico Scholz
> <enrico.scholz@sigma-chemnitz.de> wrote:
>> Enrico Scholz
>> <enrico.scholz-wttK6gPy29v+Hn7q9Vec/7NAH6kLmebB@public.gmane.org>
>> writes:
>>
>>> is it expected that recent gcc 4.8[1] compiles the kernel correctly?
>>> Kernels for ARMv5 platforms (PXA168 -> 3.4.52, MX28 -> 3.8.13) fail here
>>> 100% at early boot with
>>
>> Applying two upstream kernel commits
>> 455bd4c430b0c0a361f38e8658a0d6cb469942b5 (ARM: 7668/1: fix
>> memset-related crashes caused by recent GCC (4.7.2) optimizations) and
>> 418df63adac56841ef6b0f1fcf435bc64d4ed177 (ARM: 7670/1: fix the memset
>> fix) seem to fix the problem for me.
>
> Correct. Those are the same commits you'll see on linux-yocto-3.8, we've been
> soaking them for a while. I was waiting for LTSI and -stable to pick
> up the changes
> before updating linux-yocto-3.4, but that hasn't happened yet.
>
> If you are using linux-yocto-3.4 and can confirm that it boots for you
> with those patches,
> I can stage them in my tree while I wait for them to loop around.
>

Heh. Clearly I had vacation brain when I wrote this .. I merged and
pushed the two ARM gcc 4.8
fixes on June 20th, at the same time I was fixing 3.8. :)

Cheers,

Bruce

> Cheers,
>
> Bruce
>
>>
>>
>>
>> Enrico
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"



--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: kernel miscompilation with gcc 4.8 for ARMv5

[Holger Freyther]

Enrico Scholz <enrico.scholz@...> writes:

Good Morning,

> Applying two upstream kernel commits
> 455bd4c430b0c0a361f38e8658a0d6cb469942b5 (ARM: 7668/1: fix
> memset-related crashes caused by recent GCC (4.7.2) optimizations) and
> 418df63adac56841ef6b0f1fcf435bc64d4ed177 (ARM: 7670/1: fix the memset
> fix) seem to fix the problem for me.

I am in a similar situation with ARMv5. My 3.2.48 kernel randomly
crashed inside namei.c:do_lookup when de-referencing a bogus address
and after upgrading to 3.4.53 I do see crashes in the tcpv4 receive
path. Compiling my kernel with GCC 4.6.3 appears to produce a working
one. The output of the oops can be seen here[1], from what I see
I am entering this path[2] and besides the

 if (sk2) {
   sk = sk2;
   goto process;
 }

...
process:
	if (sk->sk_state == TCP_TIME_WAIT)
		goto do_time_wait;
...

will crash on the above line. Compiling tcp_ipv4.c with GCC4.6.3
and re-linking doesn't appear to fix the problem but maybe I made
another mistake.

Do you guys have an idea on how to proceed?



[1] http://paste.lisp.org/display/138095
[2] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/ipv
4/tcp_ipv4.c?id=v3.4#n1833

Re: kernel miscompilation with gcc 4.8 for ARMv5

[Phil Blundell]

On Fri, 2013-07-19 at 05:39 +0000, Holger Freyther wrote:
> will crash on the above line. Compiling tcp_ipv4.c with GCC4.6.3
> and re-linking doesn't appear to fix the problem but maybe I made
> another mistake.

If your analysis of the path that leads up to the crash is correct then
it sounds like the bug is probably in inet_hashtables.c not tcp_ipv4.c.
Does it help if you recompile that one file with the older GCC and
re-link?

p.