summaryrefslogtreecommitdiffstats
path: root/Makefile
AgeCommit message (Collapse)Author
2015-05-13Linux 3.14.42v3.14.42Greg Kroah-Hartman
2015-05-06Linux 3.14.41v3.14.41Greg Kroah-Hartman
2015-04-29Linux 3.14.40v3.14.40Greg Kroah-Hartman
2015-04-19Linux 3.14.39v3.14.39Greg Kroah-Hartman
2015-04-13Linux 3.14.38v3.14.38Greg Kroah-Hartman
2015-03-26Linux 3.14.37v3.14.37Greg Kroah-Hartman
2015-03-18Linux 3.14.36v3.14.36Greg Kroah-Hartman
2015-03-06Linux 3.14.35v3.14.35Greg Kroah-Hartman
2015-02-26Linux 3.14.34v3.14.34Greg Kroah-Hartman
2015-02-11Linux 3.14.33v3.14.33Greg Kroah-Hartman
2015-02-06Linux 3.14.32v3.14.32Greg Kroah-Hartman
2015-01-29Linux 3.14.31v3.14.31Greg Kroah-Hartman
2015-01-27Linux 3.14.30v3.14.30Greg Kroah-Hartman
2015-01-16Linux 3.14.29v3.14.29Greg Kroah-Hartman
2015-01-08Linux 3.14.28v3.14.28Greg Kroah-Hartman
2014-12-16Linux 3.14.27v3.14.27Greg Kroah-Hartman
2014-12-06Linux 3.14.26v3.14.26Greg Kroah-Hartman
2014-11-21Linux 3.14.25v3.14.25Greg Kroah-Hartman
2014-11-14Linux 3.14.24v3.14.24Greg Kroah-Hartman
2014-10-30Linux 3.14.23v3.14.23Greg Kroah-Hartman
2014-10-15Linux 3.14.22v3.14.22Greg Kroah-Hartman
2014-10-09Linux 3.14.21v3.14.21Greg Kroah-Hartman
2014-10-05Linux 3.14.20v3.14.20Greg Kroah-Hartman
2014-09-17Linux 3.14.19v3.14.19Greg Kroah-Hartman
2014-09-05Linux 3.14.18v3.14.18Greg Kroah-Hartman
2014-08-14Linux 3.14.17v3.14.17Greg Kroah-Hartman
2014-08-07Linux 3.14.16v3.14.16Greg Kroah-Hartman
2014-07-31Linux 3.14.15v3.14.15Greg Kroah-Hartman
2014-07-31Fix gcc-4.9.0 miscompilation of load_balance() in schedulerLinus Torvalds
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 <michel@daenzer.net> Suggested-by: Markus Trippelsdorf <markus@trippelsdorf.de> Cc: Jakub Jelinek <jakub@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-28Linux 3.14.14v3.14.14Greg Kroah-Hartman
2014-07-17Linux 3.14.13v3.14.13Greg Kroah-Hartman
2014-07-09Linux 3.14.12v3.14.12Greg Kroah-Hartman
2014-07-06Linux 3.14.11v3.14.11Greg Kroah-Hartman
2014-06-30Linux 3.14.10v3.14.10Greg Kroah-Hartman
2014-06-26Linux 3.14.9v3.14.9Greg Kroah-Hartman
2014-06-16Linux 3.14.8v3.14.8Greg Kroah-Hartman
2014-06-11Linux 3.14.7v3.14.7Greg Kroah-Hartman
2014-06-07Linux 3.14.6v3.14.6Greg Kroah-Hartman
2014-05-31Linux 3.14.5v3.14.5Greg Kroah-Hartman
2014-05-13Linux 3.14.4v3.14.4Greg Kroah-Hartman
2014-05-06Linux 3.14.3v3.14.3Greg Kroah-Hartman
2014-04-26Linux 3.14.2v3.14.2Greg Kroah-Hartman
2014-04-14Linux 3.14.1v3.14.1Greg Kroah-Hartman
2014-03-30Linux 3.14v3.14Linus Torvalds
2014-03-24Linux 3.14-rc8v3.14-rc8Linus Torvalds
2014-03-16Linux 3.14-rc7v3.14-rc7Linus Torvalds
2014-03-09Linux 3.14-rc6v3.14-rc6Linus Torvalds
2014-03-02Linux 3.14-rc5v3.14-rc5Linus Torvalds
2014-02-25Makefile: fix build with make 3.80 againJan Beulich
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 <jbeulich@suse.com> Acked-by: Kees Cook <keescook@chromium.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Michal Marek <mmarek@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-02-25Makefile: fix extra parenthesis typo when CC_STACKPROTECTOR_REGULAR is enabledFathi Boudra
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 <fathi.boudra@linaro.org> Acked-by: Kees Cook <keescook@chromium.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
generated by cgit 1.2.3-korg (git 2.39.0) at 2024-04-28 05:33:02 +0000