1. 26 Sep, 2018 1 commit
    • Masahiro Yamada's avatar
      kbuild: add .DELETE_ON_ERROR special target · ee83ce18
      Masahiro Yamada authored
      [ Upstream commit 9c2af1c7 ]
      
      If Make gets a fatal signal while a shell is executing, it may delete
      the target file that the recipe was supposed to update.  This is needed
      to make sure that it is remade from scratch when Make is next run; if
      Make is interrupted after the recipe has begun to write the target file,
      it results in an incomplete file whose time stamp is newer than that
      of the prerequisites files.  Make automatically deletes the incomplete
      file on interrupt unless the target is marked .PRECIOUS.
      
      The situation is just the same as when the shell fails for some reasons.
      Usually when a recipe line fails, if it has changed the target file at
      all, the file is corrupted, or at least it is not completely updated.
      Yet the file’s time stamp says that it is now up to date, so the next
      time Make runs, it will not try to update that file.
      
      However, Make does not cater to delete the incomplete target file in
      this case.  We need to add .DELETE_ON_ERROR somewhere in the Makefile
      to request it.
      
      scripts/Kbuild.include seems a suitable place to add it because it is
      included from almost all sub-makes.
      
      Please note .DELETE_ON_ERROR is not effective for phony targets.
      
      The external module building should never ever touch the kernel tree.
      The following recipe fails if include/generated/autoconf.h is missing.
      However, include/config/auto.conf is not deleted since it is a phony
      target.
      
       PHONY += include/config/auto.conf
      
       include/config/auto.conf:
               $(Q)test -e include/generated/autoconf.h -a -e $@ || (          \
               echo >&2;                                                       \
               echo >&2 "  ERROR: Kernel configuration is invalid.";           \
               echo >&2 "         include/generated/autoconf.h or $@ are missing.";\
               echo >&2 "         Run 'make oldconfig && make prepare' on kernel src to fix it."; \
               echo >&2 ;                                                      \
               /bin/false)
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ee83ce18
  2. 15 Sep, 2018 2 commits
  3. 05 Sep, 2018 2 commits
  4. 24 Aug, 2018 1 commit
    • Dirk Gouders's avatar
      kconfig: fix line numbers for if-entries in menu tree · 2f9e98db
      Dirk Gouders authored
      [ Upstream commit b2d00d7c ]
      
      The line numers for if-entries in the menu tree are off by one or more
      lines which is confusing when debugging for correctness of unrelated changes.
      
      According to the git log, commit a02f0570 (kconfig: improve
      error handling in the parser) was the last one that changed that part
      of the parser and replaced
      
      	"if_entry: T_IF expr T_EOL"
      by
      	"if_entry: T_IF expr nl"
      
      but the commit message does not state why this has been done.
      
      When reverting that part of the commit, only the line numers are
      corrected (checked with cdebug = DEBUG_PARSE in zconf.y), otherwise
      the menu tree remains unchanged (checked with zconfdump() enabled in
      conf.c).
      
      An example for the corrected line numbers:
      
      drivers/soc/Kconfig:15:source drivers/soc/tegra/Kconfig
      drivers/soc/tegra/Kconfig:4:if
      drivers/soc/tegra/Kconfig:6:if
      
      changes to:
      
      drivers/soc/Kconfig:15:source drivers/soc/tegra/Kconfig
      drivers/soc/tegra/Kconfig:1:if
      drivers/soc/tegra/Kconfig:4:if
      Signed-off-by: default avatarDirk Gouders <dirk@gouders.net>
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2f9e98db
  5. 17 Aug, 2018 1 commit
  6. 11 Jul, 2018 1 commit
    • Rasmus Villemoes's avatar
      Kbuild: fix # escaping in .cmd files for future Make · e8288549
      Rasmus Villemoes authored
      commit 9564a8cf upstream.
      
      I tried building using a freshly built Make (4.2.1-69-g8a731d1), but
      already the objtool build broke with
      
      orc_dump.c: In function ‘orc_dump’:
      orc_dump.c:106:2: error: ‘elf_getshnum’ is deprecated [-Werror=deprecated-declarations]
        if (elf_getshdrnum(elf, &nr_sections)) {
      
      Turns out that with that new Make, the backslash was not removed, so cpp
      didn't see a #include directive, grep found nothing, and
      -DLIBELF_USE_DEPRECATED was wrongly put in CFLAGS.
      
      Now, that new Make behaviour is documented in their NEWS file:
      
        * WARNING: Backward-incompatibility!
          Number signs (#) appearing inside a macro reference or function invocation
          no longer introduce comments and should not be escaped with backslashes:
          thus a call such as:
            foo := $(shell echo '#')
          is legal.  Previously the number sign needed to be escaped, for example:
            foo := $(shell echo '\#')
          Now this latter will resolve to "\#".  If you want to write makefiles
          portable to both versions, assign the number sign to a variable:
            C := \#
            foo := $(shell echo '$C')
          This was claimed to be fixed in 3.81, but wasn't, for some reason.
          To detect this change search for 'nocomment' in the .FEATURES variable.
      
      This also fixes up the two make-cmd instances to replace # with $(pound)
      rather than with \#. There might very well be other places that need
      similar fixup in preparation for whatever future Make release contains
      the above change, but at least this builds an x86_64 defconfig with the
      new make.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=197847
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      e8288549
  7. 11 Jun, 2018 1 commit
    • Nathan Chancellor's avatar
      kconfig: Avoid format overflow warning from GCC 8.1 · d58cf419
      Nathan Chancellor authored
      commit 2ae89c7a upstream.
      
      In file included from scripts/kconfig/zconf.tab.c:2485:
      scripts/kconfig/confdata.c: In function ‘conf_write’:
      scripts/kconfig/confdata.c:773:22: warning: ‘%s’ directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
        sprintf(newname, "%s%s", dirname, basename);
                            ^~
      scripts/kconfig/confdata.c:773:19: note: assuming directive output of 7 bytes
        sprintf(newname, "%s%s", dirname, basename);
                         ^~~~~~
      scripts/kconfig/confdata.c:773:2: note: ‘sprintf’ output 1 or more bytes (assuming 4104) into a destination of size 4097
        sprintf(newname, "%s%s", dirname, basename);
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      scripts/kconfig/confdata.c:776:23: warning: ‘.tmpconfig.’ directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
         sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
                             ^~~~~~~~~~~
      scripts/kconfig/confdata.c:776:3: note: ‘sprintf’ output between 13 and 4119 bytes into a destination of size 4097
         sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      Increase the size of tmpname and newname to make GCC happy.
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d58cf419
  8. 30 May, 2018 2 commits
  9. 26 Apr, 2018 3 commits
  10. 24 Mar, 2018 1 commit
    • Nick Desaulniers's avatar
      kbuild: fix linker feature test macros when cross compiling with Clang · 957435b5
      Nick Desaulniers authored
      commit 86a9df59 upstream.
      
      I was not seeing my linker flags getting added when using ld-option when
      cross compiling with Clang. Upon investigation, this seems to be due to
      a difference in how GCC vs Clang handle cross compilation.
      
      GCC is configured at build time to support one backend, that is implicit
      when compiling.  Clang is explicit via the use of `-target <triple>` and
      ships with all supported backends by default.
      
      GNU Make feature test macros that compile then link will always fail
      when cross compiling with Clang unless Clang's triple is passed along to
      the compiler. For example:
      
      $ clang -x c /dev/null -c -o temp.o
      $ aarch64-linux-android/bin/ld -E temp.o
      aarch64-linux-android/bin/ld:
      unknown architecture of input file `temp.o' is incompatible with
      aarch64 output
      aarch64-linux-android/bin/ld:
      warning: cannot find entry symbol _start; defaulting to
      0000000000400078
      $ echo $?
      1
      
      $ clang -target aarch64-linux-android- -x c /dev/null -c -o temp.o
      $ aarch64-linux-android/bin/ld -E temp.o
      aarch64-linux-android/bin/ld:
      warning: cannot find entry symbol _start; defaulting to 00000000004002e4
      $ echo $?
      0
      
      This causes conditional checks that invoke $(CC) without the target
      triple, then $(LD) on the result, to always fail.
      Suggested-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Reviewed-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarGreg Hackmann <ghackmann@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      957435b5
  11. 15 Mar, 2018 4 commits
    • Peter Zijlstra's avatar
      objtool, retpolines: Integrate objtool with retpoline support more closely · c3b9f726
      Peter Zijlstra authored
      commit d5028ba8 upstream.
      
      Disable retpoline validation in objtool if your compiler sucks, and otherwise
      select the validation stuff for CONFIG_RETPOLINE=y (most builds would already
      have it set due to ORC).
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c3b9f726
    • Peter Zijlstra's avatar
      objtool: Add module specific retpoline rules · a69898c9
      Peter Zijlstra authored
      commit ca41b97e upstream.
      
      David allowed retpolines in .init.text, except for modules, which will
      trip up objtool retpoline validation, fix that.
      Requested-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a69898c9
    • Peter Zijlstra's avatar
      objtool: Add retpoline validation · e6993149
      Peter Zijlstra authored
      commit b5bc2231 upstream.
      
      David requested a objtool validation pass for CONFIG_RETPOLINE=y enabled
      builds, where it validates no unannotated indirect  jumps or calls are
      left.
      
      Add an additional .discard.retpoline_safe section to allow annotating
      the few indirect sites that are required and safe.
      Requested-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Reviewed-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e6993149
    • James Hogan's avatar
      kbuild: Handle builtin dtb file names containing hyphens · ffced041
      James Hogan authored
      commit 55fe6da9 upstream.
      
      cmd_dt_S_dtb constructs the assembly source to incorporate a devicetree
      FDT (that is, the .dtb file) as binary data in the kernel image. This
      assembly source contains labels before and after the binary data. The
      label names incorporate the file name of the corresponding .dtb file.
      Hyphens are not legal characters in labels, so .dtb files built into the
      kernel with hyphens in the file name result in errors like the
      following:
      
      bcm3368-netgear-cvg834g.dtb.S: Assembler messages:
      bcm3368-netgear-cvg834g.dtb.S:5: Error: : no such section
      bcm3368-netgear-cvg834g.dtb.S:5: Error: junk at end of line, first unrecognized character is `-'
      bcm3368-netgear-cvg834g.dtb.S:6: Error: unrecognized opcode `__dtb_bcm3368-netgear-cvg834g_begin:'
      bcm3368-netgear-cvg834g.dtb.S:8: Error: unrecognized opcode `__dtb_bcm3368-netgear-cvg834g_end:'
      bcm3368-netgear-cvg834g.dtb.S:9: Error: : no such section
      bcm3368-netgear-cvg834g.dtb.S:9: Error: junk at end of line, first unrecognized character is `-'
      
      Fix this by updating cmd_dt_S_dtb to transform all hyphens from the file
      name to underscores when constructing the labels.
      
      As of v4.16-rc2, 1139 .dts files across ARM64, ARM, MIPS and PowerPC
      contain hyphens in their names, but the issue only currently manifests
      on Broadcom MIPS platforms, as that is the only place where such files
      are built into the kernel. For example when CONFIG_DT_NETGEAR_CVG834G=y,
      or on BMIPS kernels when the dtbs target is used (in the latter case it
      admittedly shouldn't really build all the dtb.o files, but thats a
      separate issue).
      
      Fixes: 69583551 ("MIPS: BMIPS: rename bcm96358nb4ser to bcm6358-neufbox4-sercom")
      Signed-off-by: default avatarJames Hogan <jhogan@kernel.org>
      Reviewed-by: default avatarFrank Rowand <frowand.list@gmail.com>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Michal Marek <michal.lkml@markovi.net>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Kevin Cernekee <cernekee@gmail.com>
      Cc: <stable@vger.kernel.org> # 4.9+
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ffced041
  12. 25 Feb, 2018 1 commit
    • Will Deacon's avatar
      scripts/kernel-doc: Don't fail with status != 0 if error encountered with -none · 9537ff76
      Will Deacon authored
      
      [ Upstream commit e814bccb ]
      
      My bisect scripts starting running into build failures when trying to
      compile 4.15-rc1 with the builds failing with things like:
      
      drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2078: error: Cannot parse struct or union!
      
      The line in question is actually just a #define, but after some digging
      it turns out that my scripts pass W=1 and since commit 3a025e1d
      ("Add optional check for bad kernel-doc comments") that results in
      kernel-doc running on each source file. The file in question has a
      badly formatted comment immediately before the #define:
      
      /**
       * struct brcmf_skbuff_cb reserves first two bytes in sk_buff::cb for
       * bus layer usage.
       */
      
      which causes the regex in dump_struct to fail (lack of braces following
      struct declaration) and kernel-doc returns 1, which causes the build
      to fail.
      
      Fix the issue by always returning 0 from kernel-doc when invoked with
      -none. It successfully generates no documentation, and prints out any
      issues.
      
      Cc: Matthew Wilcox <mawilcox@microsoft.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9537ff76
  13. 22 Feb, 2018 1 commit
  14. 16 Feb, 2018 2 commits
    • Arnd Bergmann's avatar
      kasan: rework Kconfig settings · 062cd346
      Arnd Bergmann authored
      commit e7c52b84 upstream.
      
      We get a lot of very large stack frames using gcc-7.0.1 with the default
      -fsanitize-address-use-after-scope --param asan-stack=1 options, which can
      easily cause an overflow of the kernel stack, e.g.
      
        drivers/gpu/drm/i915/gvt/handlers.c:2434:1: warning: the frame size of 46176 bytes is larger than 3072 bytes
        drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5650:1: warning: the frame size of 23632 bytes is larger than 3072 bytes
        lib/atomic64_test.c:250:1: warning: the frame size of 11200 bytes is larger than 3072 bytes
        drivers/gpu/drm/i915/gvt/handlers.c:2621:1: warning: the frame size of 9208 bytes is larger than 3072 bytes
        drivers/media/dvb-frontends/stv090x.c:3431:1: warning: the frame size of 6816 bytes is larger than 3072 bytes
        fs/fscache/stats.c:287:1: warning: the frame size of 6536 bytes is larger than 3072 bytes
      
      To reduce this risk, -fsanitize-address-use-after-scope is now split out
      into a separate CONFIG_KASAN_EXTRA Kconfig option, leading to stack
      frames that are smaller than 2 kilobytes most of the time on x86_64.  An
      earlier version of this patch also prevented combining KASAN_EXTRA with
      KASAN_INLINE, but that is no longer necessary with gcc-7.0.1.
      
      All patches to get the frame size below 2048 bytes with CONFIG_KASAN=y
      and CONFIG_KASAN_EXTRA=n have been merged by maintainers now, so we can
      bring back that default now.  KASAN_EXTRA=y still causes lots of
      warnings but now defaults to !COMPILE_TEST to disable it in
      allmodconfig, and it remains disabled in all other defconfigs since it
      is a new option.  I arbitrarily raise the warning limit for KASAN_EXTRA
      to 3072 to reduce the noise, but an allmodconfig kernel still has around
      50 warnings on gcc-7.
      
      I experimented a bit more with smaller stack frames and have another
      follow-up series that reduces the warning limit for 64-bit architectures
      to 1280 bytes (without CONFIG_KASAN).
      
      With earlier versions of this patch series, I also had patches to address
      the warnings we get with KASAN and/or KASAN_EXTRA, using a
      "noinline_if_stackbloat" annotation.
      
      That annotation now got replaced with a gcc-8 bugfix (see
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715) and a workaround for
      older compilers, which means that KASAN_EXTRA is now just as bad as
      before and will lead to an instant stack overflow in a few extreme
      cases.
      
      This reverts parts of commit 3f181b4d ("lib/Kconfig.debug: disable
      -Wframe-larger-than warnings with KASAN=y").  Two patches in linux-next
      should be merged first to avoid introducing warnings in an allmodconfig
      build:
        3cd890db ("media: dvb-frontends: fix i2c access helpers for KASAN")
        16c3ada8 ("media: r820t: fix r820t_write_reg for KASAN")
      
      Do we really need to backport this?
      
      I think we do: without this patch, enabling KASAN will lead to
      unavoidable kernel stack overflow in certain device drivers when built
      with gcc-7 or higher on linux-4.10+ or any version that contains a
      backport of commit c5caf21a.  Most people are probably still on
      older compilers, but it will get worse over time as they upgrade their
      distros.
      
      The warnings we get on kernels older than this should all be for code
      that uses dangerously large stack frames, though most of them do not
      cause an actual stack overflow by themselves.The asan-stack option was
      added in linux-4.0, and commit 3f181b4d ("lib/Kconfig.debug:
      disable -Wframe-larger-than warnings with KASAN=y") effectively turned
      off the warning for allmodconfig kernels, so I would like to see this
      fix backported to any kernels later than 4.0.
      
      I have done dozens of fixes for individual functions with stack frames
      larger than 2048 bytes with asan-stack, and I plan to make sure that
      all those fixes make it into the stable kernels as well (most are
      already there).
      
      Part of the complication here is that asan-stack (from 4.0) was
      originally assumed to always require much larger stacks, but that
      turned out to be a combination of multiple gcc bugs that we have now
      worked around and fixed, but sanitize-address-use-after-scope (from
      v4.10) has a much higher inherent stack usage and also suffers from at
      least three other problems that we have analyzed but not yet fixed
      upstream, each of them makes the stack usage more severe than it should
      be.
      
      Link: http://lkml.kernel.org/r/20171221134744.2295529-1-arnd@arndb.deSigned-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Andrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      062cd346
    • Andrey Konovalov's avatar
      kasan: don't emit builtin calls when sanitization is off · e186d8bf
      Andrey Konovalov authored
      commit 0e410e15 upstream.
      
      With KASAN enabled the kernel has two different memset() functions, one
      with KASAN checks (memset) and one without (__memset).  KASAN uses some
      macro tricks to use the proper version where required.  For example
      memset() calls in mm/slub.c are without KASAN checks, since they operate
      on poisoned slab object metadata.
      
      The issue is that clang emits memset() calls even when there is no
      memset() in the source code.  They get linked with improper memset()
      implementation and the kernel fails to boot due to a huge amount of KASAN
      reports during early boot stages.
      
      The solution is to add -fno-builtin flag for files with KASAN_SANITIZE :=
      n marker.
      
      Link: http://lkml.kernel.org/r/8ffecfffe04088c52c42b92739c2bd8a0bcb3f5e.1516384594.git.andreyknvl@google.comSigned-off-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Acked-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Michal Marek <michal.lkml@markovi.net>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e186d8bf
  15. 13 Feb, 2018 1 commit
  16. 07 Feb, 2018 2 commits
  17. 03 Feb, 2018 1 commit
  18. 23 Jan, 2018 2 commits
  19. 25 Dec, 2017 2 commits
    • Will Deacon's avatar
      linux/compiler.h: Split into compiler.h and compiler_types.h · a9772285
      Will Deacon authored
      commit d1515582 upstream.
      
      linux/compiler.h is included indirectly by linux/types.h via
      uapi/linux/types.h -> uapi/linux/posix_types.h -> linux/stddef.h
      -> uapi/linux/stddef.h and is needed to provide a proper definition of
      offsetof.
      
      Unfortunately, compiler.h requires a definition of
      smp_read_barrier_depends() for defining lockless_dereference() and soon
      for defining READ_ONCE(), which means that all
      users of READ_ONCE() will need to include asm/barrier.h to avoid splats
      such as:
      
         In file included from include/uapi/linux/stddef.h:1:0,
                          from include/linux/stddef.h:4,
                          from arch/h8300/kernel/asm-offsets.c:11:
         include/linux/list.h: In function 'list_empty':
      >> include/linux/compiler.h:343:2: error: implicit declaration of function 'smp_read_barrier_depends' [-Werror=implicit-function-declaration]
           smp_read_barrier_depends(); /* Enforce dependency ordering from x */ \
           ^
      
      A better alternative is to include asm/barrier.h in linux/compiler.h,
      but this requires a type definition for "bool" on some architectures
      (e.g. x86), which is defined later by linux/types.h. Type "bool" is also
      used directly in linux/compiler.h, so the whole thing is pretty fragile.
      
      This patch splits compiler.h in two: compiler_types.h contains type
      annotations, definitions and the compiler-specific parts, whereas
      compiler.h #includes compiler-types.h and additionally defines macros
      such as {READ,WRITE.ACCESS}_ONCE().
      
      uapi/linux/stddef.h and linux/linkage.h are then moved over to include
      linux/compiler_types.h, which fixes the build for h8 and blackfin.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1508840570-22169-2-git-send-email-will.deacon@arm.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a9772285
    • Josh Poimboeuf's avatar
      x86/unwind: Rename unwinder config options to 'CONFIG_UNWINDER_*' · 8af220c9
      Josh Poimboeuf authored
      commit 11af8474 upstream.
      
      Rename the unwinder config options from:
      
        CONFIG_ORC_UNWINDER
        CONFIG_FRAME_POINTER_UNWINDER
        CONFIG_GUESS_UNWINDER
      
      to:
      
        CONFIG_UNWINDER_ORC
        CONFIG_UNWINDER_FRAME_POINTER
        CONFIG_UNWINDER_GUESS
      
      ... in order to give them a more logical config namespace.
      Suggested-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/73972fc7e2762e91912c6b9584582703d6f1b8cc.1507924831.git.jpoimboe@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8af220c9
  20. 14 Dec, 2017 3 commits
    • Masahiro Yamada's avatar
      kbuild: rpm-pkg: fix jobserver unavailable warning · 8928998d
      Masahiro Yamada authored
      
      [ Upstream commit 606625be ]
      
      If "make rpm-pkg" or "make binrpm-pkg" is run with -j[jobs] option,
      the following warning message is displayed.
      
        warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
      
      Follow the suggestion.
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8928998d
    • Masahiro Yamada's avatar
      coccinelle: fix parallel build with CHECK=scripts/coccicheck · 394d0c93
      Masahiro Yamada authored
      
      [ Upstream commit d7059ca0 ]
      
      The command "make -j8 C=1 CHECK=scripts/coccicheck" produces
      lots of "coccicheck failed" error messages.
      
      Julia Lawall explained the Coccinelle behavior as follows:
      "The problem on the Coccinelle side is that it uses a subdirectory
      with the name of the semantic patch to store standard output and
      standard error for the different threads.  I didn't want to use a
      name with the pid, so that one could easily find this information
      while Coccinelle is running.  Normally the subdirectory is cleaned
      up when Coccinelle completes, so there is only one of them at a time.
      Maybe it is best to just add the pid.  There is the risk that these
      subdirectories will accumulate if Coccinelle crashes in a way such
      that they don't get cleaned up, but Coccinelle could print a warning
      if it detects this case, rather than failing."
      
      When scripts/coccicheck is used as CHECK tool and -j option is given
      to Make, the whole of build process runs in parallel.  So, multiple
      processes try to get access to the same subdirectory.
      
      I notice spatch creates the subdirectory only when it runs in parallel
      (i.e. --jobs <N> is given and <N> is greater than 1).
      
      Setting NPROC=1 is a reasonable solution; spatch does not create the
      subdirectory.  Besides, ONLINE=1 mode takes a single file input for
      each spatch invocation, so there is no reason to parallelize it in
      the first place.
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarJulia Lawall <Julia.Lawall@lip6.fr>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      394d0c93
    • Masahiro Yamada's avatar
      kbuild: pkg: use --transform option to prefix paths in tar · 54a13eb7
      Masahiro Yamada authored
      
      [ Upstream commit 2dbc644a ]
      
      For rpm-pkg and deb-pkg, a source tar file is created.  All paths in
      the archive must be prefixed with the base name of the tar so that
      everything is contained in the directory when you extract it.
      
      Currently, scripts/package/Makefile uses a symlink for that, and
      removes it after the tar is created.
      
      If you terminate the build during the tar creation, the symlink is
      left over.  Then, at the next package build, you will see a warning
      like follows:
      
        ln: '.' and 'kernel-4.14.0+/.' are the same file
      
      It is possible to fix it by adding -n (--no-dereference) option to
      the "ln" command, but a cleaner way is to use --transform option
      of "tar" command.  This option is GNU extension, but it should not
      hurt to use it in the Linux build system.
      
      The 'S' flag is needed to exclude symlinks from the path fixup.
      Without it, symlinks in the kernel are broken.
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      54a13eb7
  21. 06 Nov, 2017 1 commit
    • Tobin C. Harding's avatar
      scripts: add leaking_addresses.pl · 136fc5c4
      Tobin C. Harding authored
      Currently we are leaking addresses from the kernel to user space. This
      script is an attempt to find some of those leakages. Script parses
      `dmesg` output and /proc and /sys files for hex strings that look like
      kernel addresses.
      
      Only works for 64 bit kernels, the reason being that kernel addresses on
      64 bit kernels have 'ffff' as the leading bit pattern making greping
      possible. On 32 kernels we don't have this luxury.
      
      Scripts is _slightly_ smarter than a straight grep, we check for false
      positives (all 0's or all 1's, and vsyscall start/finish addresses).
      
      [ I think there is a lot of room for improvement here, but it's already
        useful, so I'm merging it as-is. The whole "hash %p format" series is
        expected to go into 4.15, but will not fix %x users, and will not
        incentivize people to look at what they are leaking.     - Linus ]
      Signed-off-by: default avatarTobin C. Harding <me@tobin.cc>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      136fc5c4
  22. 02 Nov, 2017 2 commits
    • Linus Torvalds's avatar
      Kbuild: don't pass "-C" to preprocessor when processing linker scripts · 5cb0512c
      Linus Torvalds authored
      For some odd historical reason, we preprocessed the linker scripts with
      "-C", which keeps comments around.  That makes no sense, since the
      comments are not meaningful for the build anyway.
      
      And it actually breaks things, since linker scripts can't have C++ style
      "//" comments in them, so keeping comments after preprocessing now
      limits us in odd and surprising ways in our header files for no good
      reason.
      
      The -C option goes back to pre-git and pre-bitkeeper times, but seems to
      have been historically used (along with "-traditional") for some
      odd-ball architectures (ia64, MIPS and SH).  It probably didn't matter
      back then either, but might possibly have been used to minimize the
      difference between the original file and the pre-processed result.
      
      The reason for this may be lost in time, but let's not perpetuate it
      only because we can't remember why we did this crazy thing.
      
      This was triggered by the recent addition of SPDX lines to the source
      tree, where people apparently were confused about why header files
      couldn't use the C++ comment format.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5cb0512c
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  23. 22 Oct, 2017 1 commit
  24. 19 Oct, 2017 1 commit
  25. 13 Oct, 2017 1 commit
    • Guenter Roeck's avatar
      scripts/kallsyms.c: ignore symbol type 'n' · 51962a9d
      Guenter Roeck authored
      gcc on aarch64 may emit synbols of type 'n' if the kernel is built with
      '-frecord-gcc-switches'.  In most cases, those symbols are reported with
      nm as
      
      	000000000000000e n $d
      
      and with objdump as
      
      	0000000000000000 l    d  .GCC.command.line	0000000000000000 .GCC.command.line
      	000000000000000e l       .GCC.command.line	0000000000000000 $d
      
      Those symbols are detected in is_arm_mapping_symbol() and ignored.
      However, if "--prefix-symbols=<prefix>" is configured as well, the
      situation is different.  For example, in efi/libstub, arm64 images are
      built with
      
      	'--prefix-alloc-sections=.init --prefix-symbols=__efistub_'.
      
      In combination with '-frecord-gcc-switches', the symbols are now reported
      by nm as:
      
      	000000000000000e n __efistub_$d
      and by objdump as:
      	0000000000000000 l    d  .GCC.command.line	0000000000000000 .GCC.command.line
      	000000000000000e l       .GCC.command.line	0000000000000000 __efistub_$d
      
      Those symbols are no longer ignored and included in the base address
      calculation.  This results in a base address of 000000000000000e, which
      in turn causes kallsyms to abort with
      
          kallsyms failure:
      	relative symbol value 0xffffff900800a000 out of range in relative mode
      
      The problem is seen in little endian arm64 builds with CONFIG_EFI
      enabled and with '-frecord-gcc-switches' set in KCFLAGS.
      
      Explicitly ignore symbols of type 'n' since those are clearly debug
      symbols.
      
      Link: http://lkml.kernel.org/r/1507136063-3139-1-git-send-email-linux@roeck-us.netSigned-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      51962a9d