aboutsummaryrefslogtreecommitdiff
path: root/Makefile
AgeCommit message (Collapse)Author
2017-03-18Linux 4.4.55Greg Kroah-Hartman
2017-03-15Linux 4.4.54Greg Kroah-Hartman
2017-03-12Linux 4.4.53Greg Kroah-Hartman
2017-02-26Linux 4.4.52Greg Kroah-Hartman
2017-02-23Linux 4.4.51Greg Kroah-Hartman
2017-02-18Linux 4.4.50Greg Kroah-Hartman
2017-02-14Linux 4.4.49Greg Kroah-Hartman
2017-02-09Linux 4.4.48Greg Kroah-Hartman
2017-02-04Linux 4.4.47Greg Kroah-Hartman
2017-02-01Linux 4.4.46Greg Kroah-Hartman
2017-01-26Linux 4.4.45Greg Kroah-Hartman
2017-01-20Linux 4.4.44Greg Kroah-Hartman
2017-01-15Linux 4.4.43Greg Kroah-Hartman
2017-01-12Linux 4.4.42Greg Kroah-Hartman
2017-01-09Linux 4.4.41Greg Kroah-Hartman
2017-01-06Linux 4.4.40Greg Kroah-Hartman
2016-12-15Linux 4.4.39Greg Kroah-Hartman
2016-12-10Linux 4.4.38Greg Kroah-Hartman
2016-12-08Linux 4.4.37Greg Kroah-Hartman
2016-12-02Linux 4.4.36Greg Kroah-Hartman
2016-11-26Linux 4.4.35Greg Kroah-Hartman
2016-11-26kbuild: Steal gcc's pie from the very beginningBorislav Petkov
commit c6a385539175ebc603da53aafb7753d39089f32e upstream. So Sebastian turned off the PIE for kernel builds but that was too late - Kbuild.include already uses KBUILD_CFLAGS and trying to disable gcc options with, say cc-disable-warning, fails: gcc -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs ... -Wno-sign-compare -fno-asynchronous-unwind-tables -Wframe-address -c -x c /dev/null -o .31392.tmp /dev/null:1:0: error: code model kernel does not support PIC mode because that returns an error and we can't disable the warning. For example in this case: KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,) which leads to gcc issuing all those warnings again. So let's turn off PIE/PIC at the earliest possible moment, when we declare KBUILD_CFLAGS so that cc-disable-warning picks it up too. Also, we need the $(call cc-option ...) because -fno-PIE is supported since gcc v3.4 and our lowest supported gcc version is 3.2 right now. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Ben Hutchings <ben@decadent.org.uk> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Michal Marek <mmarek@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-26kbuild: add -fno-PIESebastian Andrzej Siewior
commit 8ae94224c9d72fc4d9aaac93b2d7833cf46d7141 upstream. Debian started to build the gcc with -fPIE by default so the kernel build ends before it starts properly with: |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Also add to KBUILD_AFLAGS due to: |gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d … -mfentry -DCC_USING_FENTRY … vdso/vdso32/note.S |arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry isn’t supported for 32-bit in combination with -fpic Tagging it stable so it is possible to compile recent stable kernels as well. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Michal Marek <mmarek@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-11-21Linux 4.4.34Greg Kroah-Hartman
2016-11-18Linux 4.4.33Greg Kroah-Hartman
2016-11-15Linux 4.4.32Greg Kroah-Hartman
2016-11-10Linux 4.4.31Greg Kroah-Hartman
2016-11-10Disable "frame-address" warningLinus Torvalds
commit 124a3d88fa20e1869fc229d7d8c740cc81944264 upstream. Newer versions of gcc warn about the use of __builtin_return_address() with a non-zero argument when "-Wall" is specified: kernel/trace/trace_irqsoff.c: In function ‘stop_critical_timings’: kernel/trace/trace_irqsoff.c:433:86: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe [-Wframe-address] stop_critical_timing(CALLER_ADDR0, CALLER_ADDR1); [ .. repeats a few times for other similar cases .. ] It is true that a non-zero argument is somewhat dangerous, and we do not actually have very many uses of that in the kernel - but the ftrace code does use it, and as Stephen Rostedt says: "We are well aware of the danger of using __builtin_return_address() of > 0. In fact that's part of the reason for having the "thunk" code in x86 (See arch/x86/entry/thunk_{64,32}.S). [..] it adds extra frames when tracking irqs off sections, to prevent __builtin_return_address() from accessing bad areas. In fact the thunk_32.S states: 'Trampoline to trace irqs off. (otherwise CALLER_ADDR1 might crash)'." For now, __builtin_return_address() with a non-zero argument is the best we can do, and the warning is not helpful and can end up making people miss other warnings for real problems. So disable the frame-address warning on compilers that need it. Acked-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31Linux 4.4.30Greg Kroah-Hartman
2016-10-31Linux 4.4.29Greg Kroah-Hartman
2016-10-28Linux 4.4.28Greg Kroah-Hartman
2016-10-22Linux 4.4.27Greg Kroah-Hartman
2016-10-20Linux 4.4.26Greg Kroah-Hartman
2016-10-16Linux 4.4.25Greg Kroah-Hartman
2016-10-07Linux 4.4.24Greg Kroah-Hartman
2016-09-30Linux 4.4.23Greg Kroah-Hartman
2016-09-30Makefile: Mute warning for __builtin_return_address(>0) for tracing onlySteven Rostedt
commit 377ccbb483738f84400ddf5840c7dd8825716985 upstream. With the latest gcc compilers, they give a warning if __builtin_return_address() parameter is greater than 0. That is because if it is used by a function called by a top level function (or in the case of the kernel, by assembly), it can try to access stack frames outside the stack and crash the system. The tracing system uses __builtin_return_address() of up to 2! But it is well aware of the dangers that it may have, and has even added precautions to protect against it (see the thunk code in arch/x86/entry/thunk*.S) Linus originally added KBUILD_CFLAGS that would suppress the warning for the entire kernel, as simply adding KBUILD_CFLAGS to the tracing directory wouldn't work. The tracing directory plays a bit with the CFLAGS and requires a little more logic. This adds that special logic to only suppress the warning for the tracing directory. If it is used anywhere else outside of tracing, the warning will still be triggered. Link: http://lkml.kernel.org/r/20160728223043.51996267@grimm.local.home Tested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-30Disable "frame-address" warningLinus Torvalds
commit 124a3d88fa20e1869fc229d7d8c740cc81944264 upstream. Newer versions of gcc warn about the use of __builtin_return_address() with a non-zero argument when "-Wall" is specified: kernel/trace/trace_irqsoff.c: In function ‘stop_critical_timings’: kernel/trace/trace_irqsoff.c:433:86: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe [-Wframe-address] stop_critical_timing(CALLER_ADDR0, CALLER_ADDR1); [ .. repeats a few times for other similar cases .. ] It is true that a non-zero argument is somewhat dangerous, and we do not actually have very many uses of that in the kernel - but the ftrace code does use it, and as Stephen Rostedt says: "We are well aware of the danger of using __builtin_return_address() of > 0. In fact that's part of the reason for having the "thunk" code in x86 (See arch/x86/entry/thunk_{64,32}.S). [..] it adds extra frames when tracking irqs off sections, to prevent __builtin_return_address() from accessing bad areas. In fact the thunk_32.S states: 'Trampoline to trace irqs off. (otherwise CALLER_ADDR1 might crash)'." For now, __builtin_return_address() with a non-zero argument is the best we can do, and the warning is not helpful and can end up making people miss other warnings for real problems. So disable the frame-address warning on compilers that need it. Acked-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-30Disable "maybe-uninitialized" warning globallyLinus Torvalds
commit 6e8d666e925333c55378e8d5540a8a9ee0eea9c5 upstream. Several build configurations had already disabled this warning because it generates a lot of false positives. But some had not, and it was still enabled for "allmodconfig" builds, for example. Looking at the warnings produced, every single one I looked at was a false positive, and the warnings are frequent enough (and big enough) that they can easily hide real problems that you don't notice in the noise generated by -Wmaybe-uninitialized. The warning is good in theory, but this is a classic case of a warning that causes more problems than the warning can solve. If gcc gets better at avoiding false positives, we may be able to re-enable this warning. But as is, we're better off without it, and I want to be able to see the *real* warnings. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-30gcov: disable -Wmaybe-uninitialized warningArnd Bergmann
commit e72e2dfe7c16ffbfbabf9cb24adc6d9f93a4fe37 upstream. When gcov profiling is enabled, we see a lot of spurious warnings about possibly uninitialized variables being used: arch/arm/mm/dma-mapping.c: In function 'arm_coherent_iommu_map_page': arch/arm/mm/dma-mapping.c:1085:16: warning: 'start' may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/clk/st/clk-flexgen.c: In function 'st_of_flexgen_setup': drivers/clk/st/clk-flexgen.c:323:9: warning: 'num_parents' may be used uninitialized in this function [-Wmaybe-uninitialized] kernel/cgroup.c: In function 'cgroup_mount': kernel/cgroup.c:2119:11: warning: 'root' may be used uninitialized in this function [-Wmaybe-uninitialized] All of these are false positives, so it seems better to just disable the warnings whenever GCOV is enabled. Most users don't enable GCOV, and based on a prior patch, it is now also disabled for 'allmodconfig' builds, so there should be no downsides of doing this. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com> Signed-off-by: Michal Marek <mmarek@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-30Kbuild: disable 'maybe-uninitialized' warning for CONFIG_PROFILE_ALL_BRANCHESArnd Bergmann
commit 815eb71e7149ecce40db9dd0ad09c4dd9d33c60f upstream. CONFIG_PROFILE_ALL_BRANCHES confuses gcc-5.x to the degree that it prints incorrect warnings about a lot of variables that it thinks can be used uninitialized, e.g.: i2c/busses/i2c-diolan-u2c.c: In function 'diolan_usb_xfer': i2c/busses/i2c-diolan-u2c.c:391:16: warning: 'byte' may be used uninitialized in this function iio/gyro/itg3200_core.c: In function 'itg3200_probe': iio/gyro/itg3200_core.c:213:6: warning: 'val' may be used uninitialized in this function leds/leds-lp55xx-common.c: In function 'lp55xx_update_bits': leds/leds-lp55xx-common.c:350:6: warning: 'tmp' may be used uninitialized in this function misc/bmp085.c: In function 'show_pressure': misc/bmp085.c:363:10: warning: 'pressure' may be used uninitialized in this function power/ds2782_battery.c: In function 'ds2786_get_capacity': power/ds2782_battery.c:214:17: warning: 'raw' may be used uninitialized in this function These are all false positives that either rob someone's time when trying to figure out whether they are real, or they get people to send wrong patches to shut up the warnings. Nobody normally wants to run a CONFIG_PROFILE_ALL_BRANCHES kernel in production, so disabling the whole class of warnings for this configuration has no serious downsides either. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Steven Rostedt <rostedtgoodmis.org> Signed-off-by: Michal Marek <mmarek@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-30kbuild: forbid kernel directory to contain spaces and colonsRobert Jarzmik
commit 51193b76bfff5027cf96ba63effae808ad67cca7 upstream. When the kernel path contains a space or a colon somewhere in the path name, the modules_install target doesn't work anymore, as the path names are not enclosed in double quotes. It is also supposed that and O= build will suffer from the same weakness as modules_install. Instead of checking and improving kbuild to resist to directories including these characters, error out early to prevent any build if the kernel's main directory contains a space. Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Michal Marek <mmarek@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-30tools: Support relative directory path for 'O='Josh Poimboeuf
commit e17cf3a80d4ba0c4e40bf1a89deb1354c2e10e14 upstream. Running "make O=foo" (with a relative directory path) fails with: scripts/Makefile.include:3: *** O=foo does not exist. Stop. /home/jpoimboe/git/linux/Makefile:1547: recipe for target 'tools/objtool' failed The tools Makefile gets confused by the relative path and tries to build objtool in tools/foo. Convert the output directory to an absolute path before passing it to the tools Makefile. Reported-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-next@vger.kernel.org Cc: linux@roeck-us.net Cc: live-patching@vger.kernel.org Link: http://lkml.kernel.org/r/94a078c6c998fac9f01a14f574008bf7dff40191.1457016803.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-30Makefile: revert "Makefile: Document ability to make file.lst and file.S" ↵Wang YanQing
partially commit 40ab87a4003c7952976ce901a2b9ece5ed833168 upstream. Commit 627189797807 ("Makefile: Document ability to make file.lst and file.S") document ability to make file.S, but there isn't such ability in kbuild, so revert it. Signed-off-by: Wang YanQing <udknight@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-30kbuild: Do not run modules_install and install in paralelMichal Marek
commit a85a41ed69f27c4c667d8c418df14b4fb220c4ad upstream. Based on a x86-only patch by Andy Lutomirski <luto@amacapital.net> With modular kernels, 'make install' is going to need the installed modules at some point to generate the initramfs. Signed-off-by: Michal Marek <mmarek@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-24Linux 4.4.22Greg Kroah-Hartman
2016-09-15Linux 4.4.21Greg Kroah-Hartman
2016-09-07Linux 4.4.20Greg Kroah-Hartman
2016-08-20Linux 4.4.19Greg Kroah-Hartman
2016-08-16Linux 4.4.18Greg Kroah-Hartman