1. 13 2月, 2017 1 次提交
  2. 06 2月, 2017 1 次提交
  3. 04 2月, 2017 1 次提交
  4. 30 1月, 2017 1 次提交
  5. 23 1月, 2017 1 次提交
  6. 16 1月, 2017 1 次提交
  7. 09 1月, 2017 1 次提交
  8. 02 1月, 2017 1 次提交
  9. 26 12月, 2016 1 次提交
  10. 12 12月, 2016 1 次提交
  11. 05 12月, 2016 1 次提交
  12. 03 12月, 2016 1 次提交
  13. 02 12月, 2016 1 次提交
  14. 28 11月, 2016 1 次提交
  15. 21 11月, 2016 1 次提交
  16. 16 11月, 2016 1 次提交
    • B
      kbuild: Steal gcc's pie from the very beginning · c6a38553
      Borislav Petkov 提交于
      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: NBorislav Petkov <bp@suse.de>
      Cc: stable@vger.kernel.org
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      c6a38553
  17. 14 11月, 2016 1 次提交
  18. 12 11月, 2016 1 次提交
    • A
      Kbuild: enable -Wmaybe-uninitialized warning for "make W=1" · a76bcf55
      Arnd Bergmann 提交于
      Traditionally, we have always had warnings about uninitialized variables
      enabled, as this is part of -Wall, and generally a good idea [1], but it
      also always produced false positives, mainly because this is a variation
      of the halting problem and provably impossible to get right in all cases
      [2].
      
      Various people have identified cases that are particularly bad for false
      positives, and in commit e74fc973 ("Turn off -Wmaybe-uninitialized
      when building with -Os"), I turned off the warning for any build that
      was done with CC_OPTIMIZE_FOR_SIZE.  This drastically reduced the number
      of false positive warnings in the default build but unfortunately had
      the side effect of turning the warning off completely in 'allmodconfig'
      builds, which in turn led to a lot of warnings (both actual bugs, and
      remaining false positives) to go in unnoticed.
      
      With commit 877417e6 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE
      definition") enabled the warning again for allmodconfig builds in v4.7
      and in v4.8-rc1, I had finally managed to address all warnings I get in
      an ARM allmodconfig build and most other maybe-uninitialized warnings
      for ARM randconfig builds.
      
      However, commit 6e8d666e ("Disable "maybe-uninitialized" warning
      globally") was merged at the same time and disabled it completely for
      all configurations, because of false-positive warnings on x86 that I had
      not addressed until then.  This caused a lot of actual bugs to get
      merged into mainline, and I sent several dozen patches for these during
      the v4.9 development cycle.  Most of these are actual bugs, some are for
      correct code that is safe because it is only called under external
      constraints that make it impossible to run into the case that gcc sees,
      and in a few cases gcc is just stupid and finds something that can
      obviously never happen.
      
      I have now done a few thousand randconfig builds on x86 and collected
      all patches that I needed to address every single warning I got (I can
      provide the combined patch for the other warnings if anyone is
      interested), so I hope we can get the warning back and let people catch
      the actual bugs earlier.
      
      This reverts the change to disable the warning completely and for now
      brings it back at the "make W=1" level, so we can get it merged into
      mainline without introducing false positives.  A follow-up patch enables
      it on all levels unless some configuration option turns it off because
      of false-positives.
      
      Link: https://rusty.ozlabs.org/?p=232 [1]
      Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2]
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a76bcf55
  19. 09 11月, 2016 1 次提交
    • S
      kbuild: add -fno-PIE · 8ae94224
      Sebastian Andrzej Siewior 提交于
      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.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      8ae94224
  20. 06 11月, 2016 1 次提交
  21. 30 10月, 2016 1 次提交
  22. 24 10月, 2016 1 次提交
  23. 16 10月, 2016 1 次提交
  24. 13 10月, 2016 1 次提交
    • L
      Disable the __builtin_return_address() warning globally after all · ef6000b4
      Linus Torvalds 提交于
      This affectively reverts commit 377ccbb4 ("Makefile: Mute warning
      for __builtin_return_address(>0) for tracing only") because it turns out
      that it really isn't tracing only - it's all over the tree.
      
      We already also had the warning disabled separately for mm/usercopy.c
      (which this commit also removes), and it turns out that we will also
      want to disable it for get_lock_parent_ip(), that is used for at least
      TRACE_IRQFLAGS.  Which (when enabled) ends up being all over the tree.
      
      Steven Rostedt had a patch that tried to limit it to just the config
      options that actually triggered this, but quite frankly, the extra
      complexity and abstraction just isn't worth it.  We have never actually
      had a case where the warning is actually useful, so let's just disable
      it globally and not worry about it.
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Peter Anvin <hpa@zytor.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ef6000b4
  25. 10 10月, 2016 1 次提交
  26. 03 10月, 2016 1 次提交
  27. 26 9月, 2016 1 次提交
  28. 19 9月, 2016 1 次提交
  29. 12 9月, 2016 1 次提交
  30. 09 9月, 2016 2 次提交
    • N
      kbuild: add arch specific post-link Makefile · fbe6e37d
      Nicholas Piggin 提交于
      Allow architectures to create arch/xxx/Makefile.postlink with targets
      for vmlinux, modules.ko, and clean, which will be invoked after final
      linking of vmlinux and modules.
      
      powerpc will use this to check vmlinux linker relocations for sanity,
      and may use it to fix up alternate instruction patch branch addresses.
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      fbe6e37d
    • N
      kbuild: allow archs to select link dead code/data elimination · b67067f1
      Nicholas Piggin 提交于
      Introduce LD_DEAD_CODE_DATA_ELIMINATION option for architectures to
      select to build with -ffunction-sections, -fdata-sections, and link
      with --gc-sections. It requires some work (documented) to ensure all
      unreferenced entrypoints are live, and requires toolchain and build
      verification, so it is made a per-arch option for now.
      
      On a random powerpc64le build, this yelds a significant size saving,
      it boots and runs fine, but there is a lot I haven't tested as yet, so
      these savings may be reduced if there are bugs in the link.
      
          text      data        bss        dec   filename
      11169741   1180744    1923176	14273661   vmlinux
      10445269   1004127    1919707	13369103   vmlinux.dce
      
      ~700K text, ~170K data, 6% removed from kernel image size.
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      b67067f1
  31. 05 9月, 2016 1 次提交
  32. 29 8月, 2016 1 次提交
  33. 23 8月, 2016 1 次提交
  34. 22 8月, 2016 1 次提交
  35. 15 8月, 2016 1 次提交
  36. 09 8月, 2016 1 次提交
  37. 08 8月, 2016 1 次提交
  38. 03 8月, 2016 1 次提交
    • S
      Makefile: Mute warning for __builtin_return_address(>0) for tracing only · 377ccbb4
      Steven Rostedt 提交于
      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.homeTested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      377ccbb4
  39. 29 7月, 2016 1 次提交