summaryrefslogtreecommitdiffstats
path: root/Makefile
Commit message (Collapse)AuthorAgeFilesLines
* Linux 4.7.7v4.7.7Greg Kroah-Hartman2016-10-071-1/+1
|
* Linux 4.7.6v4.7.6Greg Kroah-Hartman2016-09-301-1/+1
|
* Makefile: Mute warning for __builtin_return_address(>0) for tracing onlySteven Rostedt2016-09-301-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Disable "frame-address" warningLinus Torvalds2016-09-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Disable "maybe-uninitialized" warning globallyLinus Torvalds2016-09-301-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* Linux 4.7.5v4.7.5Greg Kroah-Hartman2016-09-241-1/+1
|
* Linux 4.7.4v4.7.4Greg Kroah-Hartman2016-09-151-1/+1
|
* Linux 4.7.3v4.7.3Greg Kroah-Hartman2016-09-071-1/+1
|
* Linux 4.7.2v4.7.2Greg Kroah-Hartman2016-08-201-1/+1
|
* Linux 4.7.1v4.7.1Greg Kroah-Hartman2016-08-161-1/+1
|
* Linux 4.7v4.7Linus Torvalds2016-07-241-1/+1
|
* Linux 4.7-rc7v4.7-rc7Linus Torvalds2016-07-101-1/+1
|
* Linux 4.7-rc6v4.7-rc6Linus Torvalds2016-07-031-1/+1
|
* Merge branch 'rc-fixes' of ↵Linus Torvalds2016-06-271-0/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild Pull kbuild regression fix from Michal Marek: "The problem is that commit 9c8fa9bc08f6 ("kbuild: fix if_change and friends to consider argument order") fixed a potential missed rebuild, but this results in unnnecessary rebuilds with the packaging targets. Which is still more correct than the previous logic, but also very annoying" * 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild: kbuild: Initialize exported variables
| * kbuild: Initialize exported variablesMichal Marek2016-06-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | The NOSTDINC_FLAGS variable is exported, so it needs to be cleared to avoid duplicating its content when running make from within make (e.g. in the packaging targets). This became an issue after commit 9c8fa9bc08f6 ("kbuild: fix if_change and friends to consider argument order"), which no longer ignores the duplicate options. As Paulo Zanoni points out, the LDFLAGS_vmlinux variable has the same problem. Reported-by: "Zanoni, Paulo R" <paulo.r.zanoni@intel.com> Fixes: 9c8fa9bc08f6 ("kbuild: fix if_change and friends to consider argument order") Signed-off-by: Michal Marek <mmarek@suse.com>
* | Linux 4.7-rc5v4.7-rc5Linus Torvalds2016-06-261-1/+1
| |
* | Linux 4.7-rc4v4.7-rc4Linus Torvalds2016-06-191-1/+1
| |
* | Linux 4.7-rc3v4.7-rc3Linus Torvalds2016-06-121-1/+1
| |
* | Linux 4.7-rc2v4.7-rc2Linus Torvalds2016-06-051-1/+1
|/
* Linux 4.7-rc1v4.7-rc1Linus Torvalds2016-05-291-3/+3
|
* Merge branch 'kbuild' of ↵Linus Torvalds2016-05-261-19/+47
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild Pull kbuild updates from Michal Marek: - new option CONFIG_TRIM_UNUSED_KSYMS which does a two-pass build and unexports symbols which are not used in the current config [Nicolas Pitre] - several kbuild rule cleanups [Masahiro Yamada] - warning option adjustments for gcov etc [Arnd Bergmann] - a few more small fixes * 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild: (31 commits) kbuild: move -Wunused-const-variable to W=1 warning level kbuild: fix if_change and friends to consider argument order kbuild: fix adjust_autoksyms.sh for modules that need only one symbol kbuild: fix ksym_dep_filter when multiple EXPORT_SYMBOL() on the same line gcov: disable -Wmaybe-uninitialized warning gcov: disable tree-loop-im to reduce stack usage gcov: disable for COMPILE_TEST Kbuild: disable 'maybe-uninitialized' warning for CONFIG_PROFILE_ALL_BRANCHES Kbuild: change CC_OPTIMIZE_FOR_SIZE definition kbuild: forbid kernel directory to contain spaces and colons kbuild: adjust ksym_dep_filter for some cmd_* renames kbuild: Fix dependencies for final vmlinux link kbuild: better abstract vmlinux sequential prerequisites kbuild: fix call to adjust_autoksyms.sh when output directory specified kbuild: Get rid of KBUILD_STR kbuild: rename cmd_as_s_S to cmd_cpp_s_S kbuild: rename cmd_cc_i_c to cmd_cpp_i_c kbuild: drop redundant "PHONY += FORCE" kbuild: delete unnecessary "@:" kbuild: mark help target as PHONY ...
| * kbuild: move -Wunused-const-variable to W=1 warning levelArnd Bergmann2016-05-111-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gcc-6 started warning by default about variables that are not used anywhere and that are marked 'const', generating many false positives in an allmodconfig build, e.g.: arch/arm/mach-davinci/board-da830-evm.c:282:20: warning: 'da830_evm_emif25_pins' defined but not used [-Wunused-const-variable=] arch/arm/plat-omap/dmtimer.c:958:34: warning: 'omap_timer_match' defined but not used [-Wunused-const-variable=] drivers/bluetooth/hci_bcm.c:625:39: warning: 'acpi_bcm_default_gpios' defined but not used [-Wunused-const-variable=] drivers/char/hw_random/omap-rng.c:92:18: warning: 'reg_map_omap4' defined but not used [-Wunused-const-variable=] drivers/devfreq/exynos/exynos5_bus.c:381:32: warning: 'exynos5_busfreq_int_pm' defined but not used [-Wunused-const-variable=] drivers/dma/mv_xor.c:1139:34: warning: 'mv_xor_dt_ids' defined but not used [-Wunused-const-variable=] This is similar to the existing -Wunused-but-set-variable warning that was added in an earlier release and that we disable by default now and only enable when W=1 is set, so it makes sense to do the same here. Once we have eliminated the majority of the warnings for both, we can put them back into the default list. We probably want this in backport kernels as well, to allow building them with gcc-6 without introducing extra warnings. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Olof Johansson <olof@lixom.net> Acked-by: Lee Jones <lee.jones@linaro.org> Cc: stable@vger.kernel.org Signed-off-by: Michal Marek <mmarek@suse.com>
| * gcov: disable -Wmaybe-uninitialized warningArnd Bergmann2016-05-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * gcov: disable tree-loop-im to reduce stack usageArnd Bergmann2016-05-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enabling CONFIG_GCOV_PROFILE_ALL produces us a lot of warnings like lib/lz4/lz4hc_compress.c: In function 'lz4_compresshcctx': lib/lz4/lz4hc_compress.c:514:1: warning: the frame size of 1504 bytes is larger than 1024 bytes [-Wframe-larger-than=] After some investigation, I found that this behavior started with gcc-4.9, and opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69702. A suggested workaround for it is to use the -fno-tree-loop-im flag that turns off one of the optimization stages in gcc, so the code runs a little slower but does not use excessive amounts of stack. We could make this conditional on the gcc version, but I could not find an easy way to do this in Kbuild and the benefit would be fairly small, given that most of the gcc version in production are affected now. I'm marking this for 'stable' backports because it addresses a bug with code generation in gcc that exists in all kernel versions with the affected gcc releases. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com> Cc: stable@vger.kernel.org Signed-off-by: Michal Marek <mmarek@suse.com>
| * Kbuild: disable 'maybe-uninitialized' warning for CONFIG_PROFILE_ALL_BRANCHESArnd Bergmann2016-05-101-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * kbuild: forbid kernel directory to contain spaces and colonsRobert Jarzmik2016-05-101-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * kbuild: Fix dependencies for final vmlinux linkNicolas Pitre2016-04-271-1/+1
| | | | | | | | | | | | | | | | | | The if_changed directive is useless against phony targets. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 2441e78b1919 ("kbuild: better abstract vmlinux sequential prerequisites") Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: Michal Marek <mmarek@suse.cz>
| * kbuild: better abstract vmlinux sequential prerequisitesNicolas Pitre2016-04-261-16/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When CONFIG_TRIM_UNUSED_KSYMS=y and CONFIG_BUILD_DOCSRC=y it is possible to get the following error: ERROR: "cn_del_callback" [Documentation/connector/cn_test.ko] undefined! ERROR: "cn_add_callback" [Documentation/connector/cn_test.ko] undefined! ERROR: "cn_netlink_send" [Documentation/connector/cn_test.ko] undefined! ../scripts/Makefile.modpost:91: recipe for target '__modpost' failed It is not sufficient to do "vmlinux-dirs += Documentation" as this also depends on the headers_check target, and all of this needs to be done before adjust_autoksyms.sh is executed. Let's sort this out by gathering those sequential prerequisites in a make target of their own, separate from the vmlinux target. And by doing so, the special autoksyms_recursive target is no longer needed. Signed-off-by: Nicolas Pitre <nico@linaro.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org>
| * kbuild: fix call to adjust_autoksyms.sh when output directory specifiedNicolas Ferre2016-04-261-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a different output directory is specified during the build process (with O= or KBUILD_OUTPUT), the call to adjust_autoksyms.sh script fails with the following error: /bin/sh scripts/adjust_autoksyms.sh \ "make KBUILD_MODULES=1 -f ../Makefile autoksyms_recursive" /bin/sh: scripts/adjust_autoksyms.sh: No such file or directory make[2]: *** [vmlinux] Error 127 make[1]: *** [sub-make] Error 2 make: *** [__sub-make] Error 2 Using the absolute path with $(srctree) variable solves the problem. This is in case the CONFIG_TRIM_UNUSED_KSYMS option is specified. Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Fixes: 23121ca2b56b ("kbuild: create/adjust generated/autoksyms.h") Cc: Nicolas Pitre <nico@linaro.org> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Michal Marek <mmarek@suse.com>
| * kbuild: mark help target as PHONYMasahiro Yamada2016-04-201-0/+2
| | | | | | | | | | | | | | Obviously, the "help" should be a PHONY target. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Michal Marek <mmarek@suse.com>
| * kbuild: specify modules(_install) as PHONY rather than FORCEMasahiro Yamada2016-04-201-1/+2
| | | | | | | | | | | | | | | | As in other places, PHONY is a better fit for "modules" and "modules_install". Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Michal Marek <mmarek@suse.com>
| * kbuild: drop FORCE from PHONY targetsMasahiro Yamada2016-04-201-4/+4
| | | | | | | | | | | | | | | | These targets are marked as PHONY. No need to add FORCE to their dependency. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Michal Marek <mmarek@suse.com>
| * kbuild: build sample modules along with the rest of the kernelNicolas Pitre2016-03-291-3/+5
| | | | | | | | | | | | | | | | | | Make sample modules in parallel with the rest of the kernel rather than having them built from the vmlinux target. This makes the build slightly faster, and those modules are properly considered when adjust_autoksyms.sh is executed. Signed-off-by: Nicolas Pitre <nico@linaro.org>
| * kbuild: create/adjust generated/autoksyms.hNicolas Pitre2016-03-291-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Given the list of exported symbols needed by all modules, we can create a header file containing preprocessor defines for each of those symbols. Also, when some symbols are added and/or removed from the list, we can update the time on the corresponding files used as build dependencies for those symbols. And finally, if any symbol did change state, the corresponding source files must be rebuilt. The insertion or removal of an EXPORT_SYMBOL() entry within a module may create or remove the need for another exported symbol. This is why this operation has to be repeated until the list of needed exported symbols becomes stable. Only then the final kernel and modules link take place. Signed-off-by: Nicolas Pitre <nico@linaro.org> Acked-by: Rusty Russell <rusty@rustcorp.com.au>
| * export.h: allow for per-symbol configurable EXPORT_SYMBOL()Nicolas Pitre2016-03-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similar to include/generated/autoconf.h, include/generated/autoksyms.h will contain a list of defines for each EXPORT_SYMBOL() that we want active. The format is: #define __KSYM_<symbol_name> 1 This list will be auto-generated with another patch. For now we only include the preprocessor magic to automatically create or omit the corresponding struct kernel_symbol declaration. Given the content of include/generated/autoksyms.h may not be known in advance, an empty file is created early on to let the build proceed. Signed-off-by: Nicolas Pitre <nico@linaro.org> Acked-by: Rusty Russell <rusty@rustcorp.com.au>
* | Linux 4.6v4.6Linus Torvalds2016-05-151-1/+1
| |
* | Linux 4.6-rc7v4.6-rc7Linus Torvalds2016-05-081-1/+1
| |
* | Linux 4.6-rc6v4.6-rc6Linus Torvalds2016-05-011-2/+2
| |
* | Linux 4.6-rc5v4.6-rc5Linus Torvalds2016-04-241-1/+1
| |
* | Merge branch 'core-urgent-for-linus' of ↵Linus Torvalds2016-04-231-1/+2
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull objtool fixes from Ingo Molnar: "A handful of objtool fixes: two improvements to how warnings are printed plus a false positive warning fix, and build environment fix" * 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: objtool: Fix Makefile to properly see if libelf is supported objtool: Detect falling through to the next function objtool: Add workaround for GCC switch jump table bug
| * | objtool: Fix Makefile to properly see if libelf is supportedSteven Rostedt2016-04-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When doing a make allmodconfig, I hit the following compile error: In file included from builtin-check.c:32:0: elf.h:22:18: fatal error: gelf.h: No such file or directory compilation terminated. ... Digging into it, it appears that the $(shell ..) command in the Makefile does not give the proper result when it fails to find -lelf, and continues to compile objtool. Instead, use the "try-run" makefile macro to perform the test. This gives a proper result for both cases. Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Acked-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Bernd Petrovitsch <bernd@petrovitsch.priv.at> Cc: Borislav Petkov <bp@alien8.de> Cc: Chris J Arges <chris.j.arges@canonical.com> Cc: Jiri Slaby <jslaby@suse.cz> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michal Marek <mmarek@suse.cz> Cc: Namhyung Kim <namhyung@gmail.com> Cc: Pedro Alves <palves@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: live-patching@vger.kernel.org Fixes: 442f04c34a1a4 ("objtool: Add tool to perform compile-time stack metadata validation") Link: http://lkml.kernel.org/r/20160420153234.GA24032@home.goodmis.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
* | | Linux 4.6-rc4v4.6-rc4Linus Torvalds2016-04-171-1/+1
|/ /
* | Linux 4.6-rc3v4.6-rc3Linus Torvalds2016-04-101-1/+1
| |
* | Linux 4.6-rc2v4.6-rc2Linus Torvalds2016-04-031-1/+1
|/
* Linux 4.6-rc1v4.6-rc1Linus Torvalds2016-03-261-2/+2
|
* Merge branch 'kbuild' of ↵Linus Torvalds2016-03-241-0/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild Pull kbuild updates from Michal Marek: - make dtbs_install fix - Error handling fix fixdep and link-vmlinux.sh - __UNIQUE_ID fix for clang - Fix for if_changed_* to suppress the "is up to date." message - The kernel is built with -Werror=incompatible-pointer-types * 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild: kbuild: Add option to turn incompatible pointer check into error kbuild: suppress annoying "... is up to date." message kbuild: fixdep: Check fstat(2) return value scripts/link-vmlinux.sh: force error on kallsyms failure Kbuild: provide a __UNIQUE_ID for clang dtbsinstall: don't move target directory out of the way
| * kbuild: Add option to turn incompatible pointer check into errorDaniel Wagner2016-03-151-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the introduction of the simple wait API we have two very similar APIs in the kernel. For example wake_up() and swake_up() is only one character away. Although the compiler will warn happily the wrong usage it keeps on going an even links the kernel. Thomas and Peter would rather like to see early missuses reported as error early on. In a first attempt we tried to wrap all swait and wait calls into a macro which has an compile time type assertion. The result was pretty ugly and wasn't able to catch all wrong usages. woken_wake_function(), autoremove_wake_function() and wake_bit_function() are assigned as function pointers. Wrapping them with a macro around is not possible. Prefixing them with '_' was also not a real option because there some users in the kernel which do use them as well. All in all this attempt looked to intrusive and too ugly. An alternative is to turn the pointer type check into an error which catches wrong type uses. Obviously not only the swait/wait ones. That isn't a bad thing either. Signed-off-by: Daniel Wagner <daniel.wagner@bmw-carit.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Michal Marek <mmarek@suse.com>
* | kernel: add kcov code coverageDmitry Vyukov2016-03-221-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | kcov provides code coverage collection for coverage-guided fuzzing (randomized testing). Coverage-guided fuzzing is a testing technique that uses coverage feedback to determine new interesting inputs to a system. A notable user-space example is AFL (http://lcamtuf.coredump.cx/afl/). However, this technique is not widely used for kernel testing due to missing compiler and kernel support. kcov does not aim to collect as much coverage as possible. It aims to collect more or less stable coverage that is function of syscall inputs. To achieve this goal it does not collect coverage in soft/hard interrupts and instrumentation of some inherently non-deterministic or non-interesting parts of kernel is disbled (e.g. scheduler, locking). Currently there is a single coverage collection mode (tracing), but the API anticipates additional collection modes. Initially I also implemented a second mode which exposes coverage in a fixed-size hash table of counters (what Quentin used in his original patch). I've dropped the second mode for simplicity. This patch adds the necessary support on kernel side. The complimentary compiler support was added in gcc revision 231296. We've used this support to build syzkaller system call fuzzer, which has found 90 kernel bugs in just 2 months: https://github.com/google/syzkaller/wiki/Found-Bugs We've also found 30+ bugs in our internal systems with syzkaller. Another (yet unexplored) direction where kcov coverage would greatly help is more traditional "blob mutation". For example, mounting a random blob as a filesystem, or receiving a random blob over wire. Why not gcov. Typical fuzzing loop looks as follows: (1) reset coverage, (2) execute a bit of code, (3) collect coverage, repeat. A typical coverage can be just a dozen of basic blocks (e.g. an invalid input). In such context gcov becomes prohibitively expensive as reset/collect coverage steps depend on total number of basic blocks/edges in program (in case of kernel it is about 2M). Cost of kcov depends only on number of executed basic blocks/edges. On top of that, kernel requires per-thread coverage because there are always background threads and unrelated processes that also produce coverage. With inlined gcov instrumentation per-thread coverage is not possible. kcov exposes kernel PCs and control flow to user-space which is insecure. But debugfs should not be mapped as user accessible. Based on a patch by Quentin Casasnovas. [akpm@linux-foundation.org: make task_struct.kcov_mode have type `enum kcov_mode'] [akpm@linux-foundation.org: unbreak allmodconfig] [akpm@linux-foundation.org: follow x86 Makefile layout standards] Signed-off-by: Dmitry Vyukov <dvyukov@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Cc: syzkaller <syzkaller@googlegroups.com> Cc: Vegard Nossum <vegard.nossum@oracle.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Tavis Ormandy <taviso@google.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com> Cc: Kostya Serebryany <kcc@google.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Alexander Potapenko <glider@google.com> Cc: Kees Cook <keescook@google.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Sasha Levin <sasha.levin@oracle.com> Cc: David Drysdale <drysdale@google.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Kirill A. Shutemov <kirill@shutemov.name> Cc: Jiri Slaby <jslaby@suse.cz> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | Merge branch 'core-objtool-for-linus' of ↵Linus Torvalds2016-03-201-3/+17
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull 'objtool' stack frame validation from Ingo Molnar: "This tree adds a new kernel build-time object file validation feature (ONFIG_STACK_VALIDATION=y): kernel stack frame correctness validation. It was written by and is maintained by Josh Poimboeuf. The motivation: there's a category of hard to find kernel bugs, most of them in assembly code (but also occasionally in C code), that degrades the quality of kernel stack dumps/backtraces. These bugs are hard to detect at the source code level. Such bugs result in incorrect/incomplete backtraces most of time - but can also in some rare cases result in crashes or other undefined behavior. The build time correctness checking is done via the new 'objtool' user-space utility that was written for this purpose and which is hosted in the kernel repository in tools/objtool/. The tool's (very simple) UI and source code design is shaped after Git and perf and shares quite a bit of infrastructure with tools/perf (which tooling infrastructure sharing effort got merged via perf and is already upstream). Objtool follows the well-known kernel coding style. Objtool does not try to check .c or .S files, it instead analyzes the resulting .o generated machine code from first principles: it decodes the instruction stream and interprets it. (Right now objtool supports the x86-64 architecture.) From tools/objtool/Documentation/stack-validation.txt: "The kernel CONFIG_STACK_VALIDATION option enables a host tool named objtool which runs at compile time. It has a "check" subcommand which analyzes every .o file and ensures the validity of its stack metadata. It enforces a set of rules on asm code and C inline assembly code so that stack traces can be reliable. Currently it only checks frame pointer usage, but there are plans to add CFI validation for C files and CFI generation for asm files. For each function, it recursively follows all possible code paths and validates the correct frame pointer state at each instruction. It also follows code paths involving special sections, like .altinstructions, __jump_table, and __ex_table, which can add alternative execution paths to a given instruction (or set of instructions). Similarly, it knows how to follow switch statements, for which gcc sometimes uses jump tables." When this new kernel option is enabled (it's disabled by default), the tool, if it finds any suspicious assembly code pattern, outputs warnings in compiler warning format: warning: objtool: rtlwifi_rate_mapping()+0x2e7: frame pointer state mismatch warning: objtool: cik_tiling_mode_table_init()+0x6ce: call without frame pointer save/setup warning: objtool:__schedule()+0x3c0: duplicate frame pointer save warning: objtool:__schedule()+0x3fd: sibling call from callable instruction with changed frame pointer ... so that scripts that pick up compiler warnings will notice them. All known warnings triggered by the tool are fixed by the tree, most of the commits in fact prepare the kernel to be warning-free. Most of them are bugfixes or cleanups that stand on their own, but there are also some annotations of 'special' stack frames for justified cases such entries to JIT-ed code (BPF) or really special boot time code. There are two other long-term motivations behind this tool as well: - To improve the quality and reliability of kernel stack frames, so that they can be used for optimized live patching. - To create independent infrastructure to check the correctness of CFI stack frames at build time. CFI debuginfo is notoriously unreliable and we cannot use it in the kernel as-is without extra checking done both on the kernel side and on the build side. The quality of kernel stack frames matters to debuggability as well, so IMO we can merge this without having to consider the live patching or CFI debuginfo angle" * 'core-objtool-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (52 commits) objtool: Only print one warning per function objtool: Add several performance improvements tools: Copy hashtable.h into tools directory objtool: Fix false positive warnings for functions with multiple switch statements objtool: Rename some variables and functions objtool: Remove superflous INIT_LIST_HEAD objtool: Add helper macros for traversing instructions objtool: Fix false positive warnings related to sibling calls objtool: Compile with debugging symbols objtool: Detect infinite recursion objtool: Prevent infinite recursion in noreturn detection objtool: Detect and warn if libelf is missing and don't break the build tools: Support relative directory path for 'O=' objtool: Support CROSS_COMPILE x86/asm/decoder: Use explicitly signed chars objtool: Enable stack metadata validation on 64-bit x86 objtool: Add CONFIG_STACK_VALIDATION option objtool: Add tool to perform compile-time stack metadata validation x86/kprobes: Mark kretprobe_trampoline() stack frame as non-standard sched: Always inline context_switch() ...
| * | objtool: Detect and warn if libelf is missing and don't break the buildJosh Poimboeuf2016-03-051-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With CONFIG_STACK_VALIDATION enabled, if the host system doesn't have a development version of libelf installed, the build fails with errors like: elf.h:22:18: fatal error: gelf.h: No such file or directory compilation terminated. Instead of failing to build, instead just print a warning and disable stack validation. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com> 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/8c27fe00face60f42e888ddb3142c97e45223165.1457026550.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-22 04:32:54 +0000