kernel/linux.git/Makefile, branch v3.16.2

Linux 3.16.2

2014-09-05T23:37:11+00:00

Linux 3.16.1

2014-08-14T02:36:35+00:00

Linux 3.16

2014-08-03T22:25:02+00:00

Linux 3.16-rc7

2014-07-27T19:41:55+00:00

Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

2014-07-26T21:52:01+00:00

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 Cc: stable@kernel.org Signed-off-by: Linus Torvalds

Linux 3.16-rc6

2014-07-21T04:04:16+00:00

Linux 3.16-rc5

2014-07-13T21:04:33+00:00

Merge branch 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild

2014-07-11T01:40:47+00:00

Pull kbuild fixes from Michal Marek: "Three more fixes for the relative build dir feature: - Shut up make -s again - Fix for rpm/deb/tar-pkg with O= - Fix for CONFIG_EXTRA_FIRMWARE" * 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild: firmware: Create directories for external firmware kbuild: Fix packaging targets with relative $(srctree) kbuild: Do not print the build directory with make -s

Linux 3.16-rc4

2014-07-06T19:37:51+00:00

kbuild: Fix packaging targets with relative $(srctree)

2014-07-04T20:58:55+00:00

All other users of Makefile.build set $(obj) to the name of the subdirectory to build. Do the same for the packaging targets, otherwise the build fails if $(srctree) is a relative directory: $ make O=build tar-pkg make[1]: Entering directory `/home/mmarek/linux-2.6/build' CHK include/config/kernel.release ../scripts/Makefile.build:44: ../../scripts/package/Makefile: No such file or directory make[2]: *** No rule to make target `../../scripts/package/Makefile'. Stop. Fixes: 9da0763b ("kbuild: Use relative path when building in a subdir of the source tree") Signed-off-by: Michal Marek