Eric Lee / smarc-ti-linux-kernel

26 Sep, 2014

1 commit

04 Sep, 2014

1 commit

26 Aug, 2014

1 commit

31 Jul, 2014

2 commits

  • d83a3234d   Linux 3.12.26 Browse Code »
    Jiri Slaby
     
  • 5c8c5c98c   Fix gcc-4.9.0 miscompilation of load_balance() in scheduler ... Browse Code »

    commit 2062afb4f804afef61cbe62a30cac9a46e58e067 upstream.

    Michel Dänzer and a couple of other people reported inexplicable random
    oopses in the scheduler, and the cause turns out to be gcc mis-compiling
    the load_balance() function when debugging is enabled. The gcc bug
    apparently goes back to gcc-4.5, but slight optimization changes means
    that it now showed up as a problem in 4.9.0 and 4.9.1.

    The instruction scheduling problem causes gcc to schedule a spill
    operation to before the stack frame has been created, which in turn can
    corrupt the spilled value if an interrupt comes in. There may be other
    effects of this bug too, but that's the code generation problem seen in
    Michel's case.

    This is fixed in current gcc HEAD, but the workaround as suggested by
    Markus Trippelsdorf is pretty simple: use -fno-var-tracking-assignments
    when compiling the kernel, which disables the gcc code that causes the
    problem. This can result in slightly worse debug information for
    variable accesses, but that is infinitely preferable to actual code
    generation problems.

    Doing this unconditionally (not just for CONFIG_DEBUG_INFO) also allows
    non-debug builds to verify that the debug build would be identical: we
    can do

    export GCC_COMPARE_DEBUG=1

    to make gcc internally verify that the result of the build is
    independent of the "-g" flag (it will make the compiler build everything
    twice, toggling the debug flag, and compare the results).

    Without the "-fno-var-tracking-assignments" option, the build would fail
    (even with 4.8.3 that didn't show the actual stack frame bug) with a gcc
    compare failure.

    See also gcc bugzilla:

    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801

    Reported-by: Michel Dänzer
    Suggested-by: Markus Trippelsdorf
    Cc: Jakub Jelinek
    Signed-off-by: Linus Torvalds
    Signed-off-by: Jiri Slaby

    Linus Torvalds
     

18 Jul, 2014

1 commit

04 Jul, 2014

1 commit

23 Jun, 2014

1 commit

11 Jun, 2014

1 commit

29 May, 2014

1 commit

15 May, 2014

1 commit

05 May, 2014

1 commit

18 Apr, 2014

1 commit

03 Apr, 2014

1 commit

31 Mar, 2014

1 commit

24 Mar, 2014

1 commit

10 Mar, 2014

1 commit

23 Feb, 2014

1 commit

21 Feb, 2014

1 commit

14 Feb, 2014

1 commit

07 Feb, 2014

1 commit

26 Jan, 2014

1 commit

16 Jan, 2014

1 commit

10 Jan, 2014

1 commit

20 Dec, 2013

1 commit

12 Dec, 2013

1 commit

09 Dec, 2013

1 commit

05 Dec, 2013

1 commit

30 Nov, 2013

1 commit

21 Nov, 2013

1 commit

04 Nov, 2013

1 commit

28 Oct, 2013

1 commit

20 Oct, 2013

1 commit

14 Oct, 2013

1 commit

07 Oct, 2013

1 commit

30 Sep, 2013

1 commit

24 Sep, 2013

1 commit

17 Sep, 2013

1 commit

12 Sep, 2013

1 commit

  • d5d04bb48   Bye, bye, WfW flag ... Browse Code »

    This reverts the Linux for Workgroups thing. And no, before somebody
    asks, we're not doing Linux95. Not for a few years, at least.

    Sure, the flag added some color to the logo, and could have remained as
    a testament to my leet gimp skills. But no. And I'll do this early, to
    avoid the chance of forgetting when I'm doing the actual rc1 release on
    the road.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

08 Sep, 2013

1 commit