1. 11 7月, 2016 1 次提交
  2. 04 7月, 2016 1 次提交
  3. 27 6月, 2016 1 次提交
  4. 20 6月, 2016 1 次提交
  5. 12 6月, 2016 1 次提交
  6. 08 6月, 2016 1 次提交
    • M
      kbuild: Initialize exported variables · b36fad65
      Michal Marek 提交于
      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
      9c8fa9bc ("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: N"Zanoni, Paulo R" <paulo.r.zanoni@intel.com>
      Fixes: 9c8fa9bc ("kbuild: fix if_change and friends to consider argument order")
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      b36fad65
  7. 06 6月, 2016 1 次提交
  8. 30 5月, 2016 1 次提交
  9. 16 5月, 2016 1 次提交
  10. 11 5月, 2016 1 次提交
    • A
      kbuild: move -Wunused-const-variable to W=1 warning level · c9c6837d
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NOlof Johansson <olof@lixom.net>
      Acked-by: NLee Jones <lee.jones@linaro.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      c9c6837d
  11. 10 5月, 2016 4 次提交
    • A
      gcov: disable -Wmaybe-uninitialized warning · e72e2dfe
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NPeter Oberparleiter <oberpar@linux.vnet.ibm.com>
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      e72e2dfe
    • A
      gcov: disable tree-loop-im to reduce stack usage · c87bf431
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NPeter Oberparleiter <oberpar@linux.vnet.ibm.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      c87bf431
    • A
      Kbuild: disable 'maybe-uninitialized' warning for CONFIG_PROFILE_ALL_BRANCHES · 815eb71e
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      Acked-by: Steven Rostedt <rostedtgoodmis.org>
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      815eb71e
    • R
      kbuild: forbid kernel directory to contain spaces and colons · 51193b76
      Robert Jarzmik 提交于
      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: NRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      51193b76
  12. 09 5月, 2016 1 次提交
  13. 02 5月, 2016 1 次提交
  14. 27 4月, 2016 1 次提交
  15. 26 4月, 2016 2 次提交
    • N
      kbuild: better abstract vmlinux sequential prerequisites · 2441e78b
      Nicolas Pitre 提交于
      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: NNicolas Pitre <nico@linaro.org>
      Acked-by: NRandy Dunlap <rdunlap@infradead.org>
      Tested-by: NRandy Dunlap <rdunlap@infradead.org>
      2441e78b
    • N
      kbuild: fix call to adjust_autoksyms.sh when output directory specified · ba79d401
      Nicolas Ferre 提交于
      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: NNicolas Ferre <nicolas.ferre@atmel.com>
      Fixes: 23121ca2 ("kbuild: create/adjust generated/autoksyms.h")
      Cc: Nicolas Pitre <nico@linaro.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      ba79d401
  16. 25 4月, 2016 1 次提交
  17. 22 4月, 2016 1 次提交
    • S
      objtool: Fix Makefile to properly see if libelf is supported · c2bb9e32
      Steven Rostedt 提交于
      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: NSteven Rostedt <rostedt@goodmis.org>
      Acked-by: NJosh 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: 442f04c3 ("objtool: Add tool to perform compile-time stack metadata validation")
      Link: http://lkml.kernel.org/r/20160420153234.GA24032@home.goodmis.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      c2bb9e32
  18. 20 4月, 2016 3 次提交
  19. 18 4月, 2016 1 次提交
  20. 11 4月, 2016 1 次提交
  21. 03 4月, 2016 1 次提交
  22. 30 3月, 2016 3 次提交
    • N
      kbuild: build sample modules along with the rest of the kernel · dd92478a
      Nicolas Pitre 提交于
      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: NNicolas Pitre <nico@linaro.org>
      dd92478a
    • N
      kbuild: create/adjust generated/autoksyms.h · 23121ca2
      Nicolas Pitre 提交于
      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: NNicolas Pitre <nico@linaro.org>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      23121ca2
    • N
      export.h: allow for per-symbol configurable EXPORT_SYMBOL() · f2355416
      Nicolas Pitre 提交于
      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: NNicolas Pitre <nico@linaro.org>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      f2355416
  23. 27 3月, 2016 1 次提交
  24. 23 3月, 2016 1 次提交
    • D
      kernel: add kcov code coverage · 5c9a8750
      Dmitry Vyukov 提交于
      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: NDmitry Vyukov <dvyukov@google.com>
      Reviewed-by: NKees 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5c9a8750
  25. 16 3月, 2016 1 次提交
    • D
      kbuild: Add option to turn incompatible pointer check into error · ea8daa7b
      Daniel Wagner 提交于
      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: NDaniel Wagner <daniel.wagner@bmw-carit.de>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      ea8daa7b
  26. 14 3月, 2016 1 次提交
  27. 07 3月, 2016 1 次提交
  28. 05 3月, 2016 2 次提交
    • I
      Revert "kbuild: Add option to turn incompatible pointer check into error" · ca031745
      Ingo Molnar 提交于
      This reverts commit ef50c046.
      
      So adding -Werror=incompatible-pointer-types wasn't a bad idea, but it
      should really not be done in the scheduler tree: it exposes us to a
      number of pre-existing warnings (most of them harmless), now upgraded
      to build failures...
      
      This should be done via the kbuild tree.
      
      Cc: Daniel Wagner <daniel.wagner@bmw-carit.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: linux-rt-users@vger.kernel.org
      Cc: Boqun Feng <boqun.feng@gmail.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: linux-kernel@vger.kernel.org
      ca031745
    • J
      objtool: Detect and warn if libelf is missing and don't break the build · 3b27a0c8
      Josh Poimboeuf 提交于
      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: NJosh 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.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      3b27a0c8
  29. 03 3月, 2016 1 次提交
  30. 29 2月, 2016 2 次提交