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  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:	Fri, 25 Jul 2014 10:25:03 +0900
From:	Michel Dänzer <>
To:	Linus Torvalds <>,
	Jakub Jelinek <>
CC:	Linux Kernel Mailing List <>,
	Debian GCC Maintainers <>,
	Debian Kernel Team <>
Subject: Re: Random panic in load_balance() with 3.16-rc

[ Adding the Debian kernel and gcc teams to Cc ]

On 25.07.2014 03:47, Linus Torvalds wrote:
> On Wed, Jul 23, 2014 at 6:43 PM, Michel Dänzer <> wrote:
>>> Michel, mind doing
>>>     make kernel/sched/fair.s
>>> and sending us the resulting file?
>> Here it is, gzipped, hope that's okay.
>> Note that my tree is now based on 3.16-rc6.
> Ok, so I'm looking at the code generation and your compiler is pure
> and utter *shit*.
> Adding Jakub to the cc, because gcc-4.9.0 seems to be terminally broken.
> Lookie here, your compiler does some absolutely insane things with the
> spilling, including spilling a *constant*. For chrissake, that
> compiler shouldn't have been allowed to graduate from kindergarten.
> We're talking "sloth that was dropped on the head as a baby" level
> retardation levels here:
>         ...
>         movq    $load_balance_mask, -136(%rbp)  #, %sfp
>         subq    $184, %rsp      #,
>         movq    (%rdx), %rax    # sd_22(D)->parent, sd_parent
>         movl    %edi, -144(%rbp)        # this_cpu, %sfp
>         movl    %ecx, -140(%rbp)        # idle, %sfp
>         movq    %r8, -200(%rbp) # continue_balancing, %sfp
>         movq    %rax, -184(%rbp)        # sd_parent, %sfp
>         movq    -136(%rbp), %rax        # %sfp, tcp_ptr__
> #APP
>         add %gs:this_cpu_off, %rax      # this_cpu_off, tcp_ptr__
>         ...
> Note the contents of -136(%rbp). Seriously. That's an
> _immediate_constant_ that the compiler is spilling.
> Somebody needs to raise that as a gcc bug. Because it damn well is
> some seriously crazy shit.
> However, that constant spilling part just counts as "too stupid to
> live". The real bug is this:
>         movq    $load_balance_mask, -136(%rbp)  #, %sfp
>         subq    $184, %rsp      #,
> where gcc creates the stack frame *after* having already used it to
> save that constant *deep* below the stack frame.
> The x86-64 ABI specifies a 128-byte red-zone under the stack pointer,
> and this is ok by that limit. It looks like it's illegal (136 > 128),
> but the fact is, we've had four "pushq"s to update %rsp since loading
> the frame pointer, so it's just *barely* legal with the red-zoning.
> But we build the kernel with -mno-red-zone. We do *not* follow the
> x86-64 ABI wrt redzoning, because we *cannot*: interrupts while in
> kernel mode *will* use the stack without a redzone. So that
> "-mno-red-zone" is not some "optional guideline". It's a hard and
> harsh requirement for the kernel, and gcc-4.9 is a buggy piece of shit
> for ignoring it. And your bug happens becuase you happen to hit an
> interrupt _just_ in that single instruction window (or perhaps hit
> some other similar case and corrupted kernel data structures earlier).
> Now, I suspect that this redzoning bug might actually be related to
> the fact that gcc is stupid in spilling a constant. I would not be
> surprised if there is some liveness analysis going on to decide *when*
> to insert the stack decrement, and constants are being ignored because
> clearly liveness isn't an issue for a constant value. So the two bugs
> ("stupid constant spilling" and "invalid use or red zone stack") go
> hand in hand. But who knows.
> Anyway, this is not a kernel bug. This is your compiler creating
> completely broken code. We may need to add a warning to make sure
> nobody compiles with gcc-4.9.0, and the Debian people should probably
> downgrate their shiny new compiler.

Attached is fair.s from Debian gcc 4.8.3-5. Does that look better? I'm
going to try reproducing the problem with a kernel built by that now.

Earthling Michel Dänzer            |        
Libre software enthusiast          |                Mesa and X developer

Download attachment "fair.s-4.8.3-5.gz" of type "application/gzip" (185309 bytes)

Powered by blists - more mailing lists