09 Jan, 2015
1 commit
17 Dec, 2014
1 commit
07 Dec, 2014
1 commit
22 Nov, 2014
1 commit
15 Nov, 2014
1 commit
31 Oct, 2014
1 commit
15 Oct, 2014
1 commit
10 Oct, 2014
1 commit
06 Oct, 2014
1 commit
18 Sep, 2014
1 commit
06 Sep, 2014
1 commit
14 Aug, 2014
1 commit
08 Aug, 2014
1 commit
01 Aug, 2014
2 commits
-
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 doexport 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: Greg Kroah-Hartman
28 Jul, 2014
1 commit
18 Jul, 2014
1 commit
10 Jul, 2014
1 commit
07 Jul, 2014
1 commit
01 Jul, 2014
1 commit
27 Jun, 2014
1 commit
17 Jun, 2014
1 commit
12 Jun, 2014
1 commit
08 Jun, 2014
1 commit
01 Jun, 2014
1 commit
13 May, 2014
1 commit
06 May, 2014
1 commit
27 Apr, 2014
1 commit
14 Apr, 2014
1 commit
31 Mar, 2014
1 commit
25 Mar, 2014
1 commit
17 Mar, 2014
1 commit
10 Mar, 2014
1 commit
03 Mar, 2014
1 commit
26 Feb, 2014
2 commits
-
According to Documentation/Changes, make 3.80 is still being supported
for building the kernel, hence make files must not make (unconditional)
use of features introduced only in newer versions. Commit 8779657d29c0
("stackprotector: Introduce CONFIG_CC_STACKPROTECTOR_STRONG") however
introduced an "else ifdef" construct which make 3.80 doesn't understand.Also correct a warning message still referencing the old config option
name.Apart from that I question the use of "ifdef" here (but it was used that
way already prior to said commit): ifeq (,y) would seem more to the
point.Signed-off-by: Jan Beulich
Acked-by: Kees Cook
Cc: Ingo Molnar
Cc: Michal Marek
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
An extra parenthesis typo introduced in 19952a92037e ("stackprotector:
Unify the HAVE_CC_STACKPROTECTOR logic between architectures") is
causing the following error when CONFIG_CC_STACKPROTECTOR_REGULAR is
enabled:Makefile:608: Cannot use CONFIG_CC_STACKPROTECTOR: -fstack-protector not supported by compiler
Makefile:608: *** missing separator. Stop.Signed-off-by: Fathi Boudra
Acked-by: Kees Cook
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
24 Feb, 2014
1 commit
17 Feb, 2014
1 commit
10 Feb, 2014
1 commit
03 Feb, 2014
1 commit