1. 01 Apr, 2018 1 commit
  2. 25 Mar, 2018 11 commits
    • Linus Torvalds's avatar
      Linux 4.16-rc7 · 3eb2ce82
      Linus Torvalds authored
      3eb2ce82
    • Masahiro Yamada's avatar
      kbuild: add PYTHON2 and PYTHON3 variables · e9781b52
      Masahiro Yamada authored
      The variable 'PYTHON' allows users to specify a proper executable
      name in case the default 'python' does not work.  However, this does
      not address the case where both Python 2.x and 3.x scripts are used
      in one source tree.
      
      PEP 394 (https://www.python.org/dev/peps/pep-0394/) provides a
      convention for Python scripts portability.  Here is a quotation:
      
        In order to tolerate differences across platforms, all new code
        that needs to invoke the Python interpreter should not specify
        'python', but rather should specify either 'python2' or 'python3'.
        This distinction should be made in shebangs, when invoking from a
        shell script, when invoking via the system() call, or when invoking
        in any other context.
        One exception to this is scripts that are deliberately written to
        be source compatible with both Python 2.x and 3.x. Such scripts may
        continue to use python on their shebang line without affecting their
        portability.
      
      To meet this requirement, this commit adds new variables 'PYTHON2'
      and 'PYTHON3'.
      
      arch/ia64/scripts/unwcheck.py is the only script that has ever used
      $(PYTHON).  Recent commit bd5edbe6 ("ia64: convert unwcheck.py to
      python3") converted it to be compatible with both Python 2.x and 3.x,
      so this is the exceptional case where the use of 'python' is allowed.
      So, I did not touch arch/ia64/Makefile.
      
      tools/perf/Makefile.config sets PYTHON and PYTHON2 by itself, so it
      is not affected by this commit.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      e9781b52
    • Masahiro Yamada's avatar
      kconfig: rename silentoldconfig to syncconfig · 911a91c3
      Masahiro Yamada authored
      As commit cedd55d4 ("kconfig: Remove silentoldconfig from help
      and docs; fix kconfig/conf's help") mentioned, 'silentoldconfig' is a
      historical misnomer.  That commit removed it from help and docs since
      it is an internal interface.  If so, it should be allowed to rename
      it to something more intuitive.  'syncconfig' is the one I came up
      with because it updates the .config if necessary, then synchronize
      include/generated/autoconf.h and include/config/* with it.
      
      You should not manually invoke 'silentoldcofig'.  Display warning if
      used in case existing scripts are doing wrong.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: default avatarUlf Magnusson <ulfalizer@gmail.com>
      911a91c3
    • Masahiro Yamada's avatar
      kbuild: link vmlinux only once for CONFIG_TRIM_UNUSED_KSYMS · 3fdc7d3f
      Masahiro Yamada authored
      If CONFIG_TRIM_UNUSED_KSYMS is enabled and the kernel is built from
      a pristine state, the vmlinux is linked twice.
      
      [1] A user runs 'make'
      
      [2] First build with empty autoksyms.h
      
      [3] adjust_autoksyms.sh updates autoksyms.h and recurses 'make vmlinux'
      
        --------(begin sub-make)--------
        [4] Second build with new autoksyms.h
      
        [5] link-vmlinux.sh is invoked because vmlinux is missing
        ---------(end sub-make)---------
      
      [6] link-vmlinux.sh is invoked again despite vmlinux is up-to-date.
      
      The reason of [6] is probably because Make already decided to update
      vmlinux at the time of [2] because vmlinux was missing when Make
      built up the dependency graph.
      
      Because if_changed is implemented based on $?, this issue can be
      narrowed down to how Make handles $?.
      
      You can test it with the following simple code:
      
      [Test Makefile]
        A: B
                @echo newer prerequisite: $?
                cp B A
      
        B: C
                cp C B
                touch A
      
      [Result]
        $ rm -f A B
        $ touch C
        $ make
        cp C B
        touch A
        newer prerequisite: B
        cp B A
      
      Here, 'A' has been touched in the recipe of 'B'.  So, the dependency
      'A: B' has already been met before the recipe of 'A' is executed.
      However, Make does not notice the fact that the recipe of 'B' also
      updates 'A' as a side-effect.
      
      The situation is similar in this case; the vmlinux has actually been
      updated in the vmlinux_prereq target.  Make cannot predict this, so
      judges the vmlinux is old.
      
      link-vmlinux.sh is costly, so it is better to not run it when unneeded.
      Split CONFIG_TRIM_UNUSED_KSYMS recursion to a dedicated target.
      
      The reason of commit 2441e78b ("kbuild: better abstract vmlinux
      sequential prerequisites") was to cater to CONFIG_BUILD_DOCSRC, but
      it was later removed by commit 18489292 ("samples: move blackfin
      gptimers-example from Documentation").
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      3fdc7d3f
    • Masahiro Yamada's avatar
      kbuild: move include/config/ksym/* to include/ksym/* · fbfa9be9
      Masahiro Yamada authored
      The idea of using fixdep was inspired by Kconfig, but autoksyms
      belongs to a different group.  So, I want to move those touched
      files under include/config/ksym/ to include/ksym/.
      
      The directory include/ksym/ can be removed by 'make clean' because
      it is meaningless for the external module building.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      fbfa9be9
    • Masahiro Yamada's avatar
      kbuild: move CONFIG_TRIM_UNUSED_KSYMS code unneeded for external module · 1f50b80a
      Masahiro Yamada authored
      The external module building does not need to parse this code because
      KBUILD_MODULES is always set anyway.
      
      Move this code inside the "ifeq ($(KBUILD_EXTMOD),) ... endif" block.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      1f50b80a
    • Masahiro Yamada's avatar
      kbuild: restore autoksyms.h touch to the top Makefile · 07a422bb
      Masahiro Yamada authored
      Commit d3fc425e ("kbuild: make sure autoksyms.h exists early")
      moved the code that touches autoksyms.h to scripts/kconfig/Makefile
      with obscure reason.
      
      From Nicolas' comment [1], he did not seem to be sure about the root
      cause.
      
      I guess I figured it out, so here is a fix-up I think is more correct.
      According to the error log in the original post [2], the build failed
      in scripts/mod/devicetable-offsets.c
      
      scripts/mod/Makefile is descended from scripts/Makefile, which is
      invoked from the top-level Makefile by the 'scripts' target.
      
      To build vmlinux and/or modules, Kbuild descend into $(vmlinux-dirs).
      This depends on 'prepare' and 'scripts' as follows:
      
        $(vmlinux-dirs): prepare scripts
      
      Because there is no dependency between 'prepare' and 'scripts', the
      parallel building can execute them simultaneously.
      
      'prepare' depends on 'prepare1', which touched autoksyms.h, while
      'scripts' descends into script/, then scripts/mod/, which needs
      <generated/autoksyms.h> if CONFIG_TRIM_UNUSED_KSYMS.  It was the
      reason of the race.
      
      I am not happy to have unrelated code in the Kconfig Makefile, so
      getting it back to the top Makefile.
      
      I removed the standalone test target because I want to use it to
      create an empty autoksyms.h file.  Here is a little improvement;
      unnecessary autoksyms.h is not created when CONFIG_TRIM_UNUSED_KSYMS
      is disabled.
      
      [1] https://lkml.org/lkml/2016/11/30/734
      [2] https://lkml.org/lkml/2016/11/30/531Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      07a422bb
    • Masahiro Yamada's avatar
      kbuild: move 'scripts' target below · d8821622
      Masahiro Yamada authored
      Just a trivial change to prepare for the next commit.
      This target is still invisible from external module building.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      d8821622
    • Masahiro Yamada's avatar
      kbuild: clear LDFLAGS in the top Makefile · ce99d0bf
      Masahiro Yamada authored
      Currently LDFLAGS is not cleared, so same flags are accumulated in
      LDFLAGS when the top Makefile is recursively invoked.
      
      I found unneeded rebuild for ARCH=arm64 when CONFIG_TRIM_UNUSED_KSYMS
      is enabled.  If include/generated/autoksyms.h is updated, the top
      Makefile is recursively invoked, then arch/arm64/Makefile adds one
      more '-maarch64linux'.  Due to the command line change, modules are
      rebuilt needlessly.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      ce99d0bf
    • Masahiro Yamada's avatar
      kbuild: process mixture of clean/build targets one by one · 22340a06
      Masahiro Yamada authored
      Support parallel building of clean, config, and build targets in a
      single command.
      
      For example,
      
        make -j<N> clean all
      
      or
      
        make -j<N> mrproper defconfig all
      
      They should be handled one by one.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      22340a06
    • Nicholas Piggin's avatar
      kbuild: rename built-in.o to built-in.a · f49821ee
      Nicholas Piggin authored
      Incremental linking is gone, so rename built-in.o to built-in.a, which
      is the usual extension for archive files.
      
      This patch does two things, first is a simple search/replace:
      
      git grep -l 'built-in\.o' | xargs sed -i 's/built-in\.o/built-in\.a/g'
      
      The second is to invert nesting of nested text manipulations to avoid
      filtering built-in.a out from libs-y2:
      
      -libs-y2 := $(filter-out %.a, $(patsubst %/, %/built-in.a, $(libs-y)))
      +libs-y2 := $(patsubst %/, %/built-in.a, $(filter-out %.a, $(libs-y)))
      Signed-off-by: default avatarNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      f49821ee
  3. 21 Mar, 2018 2 commits
    • Stefan Agner's avatar
      kbuild: set no-integrated-as before incl. arch Makefile · 0f0e8de3
      Stefan Agner authored
      In order to make sure compiler flag detection for ARM works
      correctly the no-integrated-as flags need to be set before
      including the arch specific Makefile.
      
      Fixes: cfe17c9b ("kbuild: move cc-option and cc-disable-warning after incl. arch Makefile")
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      0f0e8de3
    • Daniel Borkmann's avatar
      kbuild: disable clang's default use of -fmerge-all-constants · 87e0d4f0
      Daniel Borkmann authored
      Prasad reported that he has seen crashes in BPF subsystem with netd
      on Android with arm64 in the form of (note, the taint is unrelated):
      
        [ 4134.721483] Unable to handle kernel paging request at virtual address 800000001
        [ 4134.820925] Mem abort info:
        [ 4134.901283]   Exception class = DABT (current EL), IL = 32 bits
        [ 4135.016736]   SET = 0, FnV = 0
        [ 4135.119820]   EA = 0, S1PTW = 0
        [ 4135.201431] Data abort info:
        [ 4135.301388]   ISV = 0, ISS = 0x00000021
        [ 4135.359599]   CM = 0, WnR = 0
        [ 4135.470873] user pgtable: 4k pages, 39-bit VAs, pgd = ffffffe39b946000
        [ 4135.499757] [0000000800000001] *pgd=0000000000000000, *pud=0000000000000000
        [ 4135.660725] Internal error: Oops: 96000021 [#1] PREEMPT SMP
        [ 4135.674610] Modules linked in:
        [ 4135.682883] CPU: 5 PID: 1260 Comm: netd Tainted: G S      W       4.14.19+ #1
        [ 4135.716188] task: ffffffe39f4aa380 task.stack: ffffff801d4e0000
        [ 4135.731599] PC is at bpf_prog_add+0x20/0x68
        [ 4135.741746] LR is at bpf_prog_inc+0x20/0x2c
        [ 4135.751788] pc : [<ffffff94ab7ad584>] lr : [<ffffff94ab7ad638>] pstate: 60400145
        [ 4135.769062] sp : ffffff801d4e3ce0
        [...]
        [ 4136.258315] Process netd (pid: 1260, stack limit = 0xffffff801d4e0000)
        [ 4136.273746] Call trace:
        [...]
        [ 4136.442494] 3ca0: ffffff94ab7ad584 0000000060400145 ffffffe3a01bf8f8 0000000000000006
        [ 4136.460936] 3cc0: 0000008000000000 ffffff94ab844204 ffffff801d4e3cf0 ffffff94ab7ad584
        [ 4136.479241] [<ffffff94ab7ad584>] bpf_prog_add+0x20/0x68
        [ 4136.491767] [<ffffff94ab7ad638>] bpf_prog_inc+0x20/0x2c
        [ 4136.504536] [<ffffff94ab7b5d08>] bpf_obj_get_user+0x204/0x22c
        [ 4136.518746] [<ffffff94ab7ade68>] SyS_bpf+0x5a8/0x1a88
      
      Android's netd was basically pinning the uid cookie BPF map in BPF
      fs (/sys/fs/bpf/traffic_cookie_uid_map) and later on retrieving it
      again resulting in above panic. Issue is that the map was wrongly
      identified as a prog! Above kernel was compiled with clang 4.0,
      and it turns out that clang decided to merge the bpf_prog_iops and
      bpf_map_iops into a single memory location, such that the two i_ops
      could then not be distinguished anymore.
      
      Reason for this miscompilation is that clang has the more aggressive
      -fmerge-all-constants enabled by default. In fact, clang source code
      has a comment about it in lib/AST/ExprConstant.cpp on why it is okay
      to do so:
      
        Pointers with different bases cannot represent the same object.
        (Note that clang defaults to -fmerge-all-constants, which can
        lead to inconsistent results for comparisons involving the address
        of a constant; this generally doesn't matter in practice.)
      
      The issue never appeared with gcc however, since gcc does not enable
      -fmerge-all-constants by default and even *explicitly* states in
      it's option description that using this flag results in non-conforming
      behavior, quote from man gcc:
      
        Languages like C or C++ require each variable, including multiple
        instances of the same variable in recursive calls, to have distinct
        locations, so using this option results in non-conforming behavior.
      
      There are also various clang bug reports open on that matter [1],
      where clang developers acknowledge the non-conforming behavior,
      and refer to disabling it with -fno-merge-all-constants. But even
      if this gets fixed in clang today, there are already users out there
      that triggered this. Thus, fix this issue by explicitly adding
      -fno-merge-all-constants to the kernel's Makefile to generically
      disable this optimization, since potentially other places in the
      kernel could subtly break as well.
      
      Note, there is also a flag called -fmerge-constants (not supported
      by clang), which is more conservative and only applies to strings
      and it's enabled in gcc's -O/-O2/-O3/-Os optimization levels. In
      gcc's code, the two flags -fmerge-{all-,}constants share the same
      variable internally, so when disabling it via -fno-merge-all-constants,
      then we really don't merge any const data (e.g. strings), and text
      size increases with gcc (14,927,214 -> 14,942,646 for vmlinux.o).
      
        $ gcc -fverbose-asm -O2 foo.c -S -o foo.S
          -> foo.S lists -fmerge-constants under options enabled
        $ gcc -fverbose-asm -O2 -fno-merge-all-constants foo.c -S -o foo.S
          -> foo.S doesn't list -fmerge-constants under options enabled
        $ gcc -fverbose-asm -O2 -fno-merge-all-constants -fmerge-constants foo.c -S -o foo.S
          -> foo.S lists -fmerge-constants under options enabled
      
      Thus, as a workaround we need to set both -fno-merge-all-constants
      *and* -fmerge-constants in the Makefile in order for text size to
      stay as is.
      
        [1] https://bugs.llvm.org/show_bug.cgi?id=18538Reported-by: default avatarPrasad Sodagudi <psodagud@codeaurora.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Chenbo Feng <fengc@google.com>
      Cc: Richard Smith <richard-llvm@metafoo.co.uk>
      Cc: Chandler Carruth <chandlerc@gmail.com>
      Cc: linux-kernel@vger.kernel.org
      Tested-by: default avatarPrasad Sodagudi <psodagud@codeaurora.org>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      87e0d4f0
  4. 20 Mar, 2018 1 commit
  5. 19 Mar, 2018 1 commit
  6. 16 Mar, 2018 1 commit
    • Arnd Bergmann's avatar
      arch: remove tile port · bb9d8126
      Arnd Bergmann authored
      The Tile architecture port was added by Chris Metcalf in 2010, and
      maintained until early 2018 when he orphaned it due to his departure
      from Mellanox, and nobody else stepped up to maintain it. The product
      line is still around in the form of the BlueField SoC, but no longer
      uses the Tile architecture.
      
      There are also still products for sale with Tile-GX SoCs, notably the
      Mikrotik CCR router family. The products all use old (linux-3.3) kernels
      with lots of patches and won't be upgraded by their manufacturers. There
      have been efforts to port both OpenWRT and Debian to these, but both
      projects have stalled and are very unlikely to be continued in the future.
      
      Given that we are reasonably sure that nobody is still using the port
      with an upstream kernel any more, it seems better to remove it now while
      the port is in a good shape than to let it bitrot for a few years first.
      
      Cc: Chris Metcalf <chris.d.metcalf@gmail.com>
      Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
      Link: http://www.mellanox.com/page/npu_multicore_overview
      Link: https://jenkins.debian.net/view/rebootstrap/job/rebootstrap_tilegx_gcc7/Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      bb9d8126
  7. 12 Mar, 2018 1 commit
  8. 04 Mar, 2018 1 commit
  9. 02 Mar, 2018 1 commit
  10. 01 Mar, 2018 2 commits
    • Luc Van Oostenryck's avatar
      kbuild: disable sparse warnings about unknown attributes · 6c49f359
      Luc Van Oostenryck authored
      Currently, sparse issues warnings on code using an attribute
      it doesn't know about.
      
      One of the problem with this is that these warnings have no
      value for the developer, it's just noise for him. At best these
      warnings tell something about some deficiencies of sparse itself
      but not about a potential problem with code analyzed.
      
      A second problem with this is that sparse release are, alas,
      less frequent than new attributes are added to GCC.
      
      So, avoid the noise by asking sparse to not warn about
      attributes it doesn't know about.
      
      Reference: https://marc.info/?l=linux-sparse&m=151871600016790
      Reference: https://marc.info/?l=linux-sparse&m=151871725417322Signed-off-by: default avatarLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Acked-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Tested-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      6c49f359
    • Ulf Magnusson's avatar
      Makefile: Fix lying comment re. silentoldconfig · 61277981
      Ulf Magnusson authored
      The comment above the silentoldconfig invocation is outdated.
      'make oldconfig' updates just .config and doesn't touch the
      include/config/ tree.
      
      This came up in https://lkml.org/lkml/2018/2/12/415.
      
      While fixing the comment, make it more informative by explaining the
      purpose of the unfortunately named silentoldconfig.
      
      I can't make sense of the comment re. auto.conf.cmd and a cleaned tree.
      include/config/auto.conf and include/config/auto.conf.cmd are both
      created simultaneously by silentoldconfig (in
      scripts/kconfig/confdata.c, by conf_write_autoconf()), and nothing seems
      to remove auto.conf.cmd that wouldn't remove auto.conf. Remove that part
      of the comment rather than blindly copying it. It might be a leftover
      from an older way of doing things.
      
      The include/config/auto.conf.cmd prerequisite might be there to ensure
      that silentoldconfig gets rerun if conf_write_autoconf() fails between
      writing out auto.conf.cmd and auto.conf (a comment in the function
      indicates that auto.conf is deliberately written out last to mark
      completion of the operation). It seems the Makefile dependency between
      include/config/auto.conf and .config would already take care of that
      though, since include/config/auto.conf would still be out of date re.
      .config if the operation fails.
      
      Cop out and leave the prerequisite in for now.
      Signed-off-by: default avatarUlf Magnusson <ulfalizer@gmail.com>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      61277981
  11. 26 Feb, 2018 1 commit
  12. 21 Feb, 2018 1 commit
  13. 19 Feb, 2018 1 commit
  14. 11 Feb, 2018 1 commit
  15. 07 Feb, 2018 5 commits
  16. 28 Jan, 2018 1 commit
  17. 21 Jan, 2018 1 commit
  18. 14 Jan, 2018 1 commit
  19. 07 Jan, 2018 1 commit
  20. 31 Dec, 2017 1 commit
  21. 30 Dec, 2017 1 commit
    • Linus Torvalds's avatar
      kbuild: add '-fno-stack-check' to kernel build options · 3ce120b1
      Linus Torvalds authored
      It appears that hardened gentoo enables "-fstack-check" by default for
      gcc.
      
      That doesn't work _at_all_ for the kernel, because the kernel stack
      doesn't act like a user stack at all: it's much smaller, and it doesn't
      auto-expand on use.  So the extra "probe one page below the stack" code
      generated by -fstack-check just breaks the kernel in horrible ways,
      causing infinite double faults etc.
      
      [ I have to say, that the particular code gcc generates looks very
        stupid even for user space where it works, but that's a separate
        issue.  ]
      Reported-and-tested-by: default avatarAlexander Tsoy <alexander@tsoy.me>
      Reported-and-tested-by: default avatarToralf Förster <toralf.foerster@gmx.de>
      Cc: stable@kernel.org
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Jiri Kosina <jikos@kernel.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3ce120b1
  22. 24 Dec, 2017 1 commit
  23. 18 Dec, 2017 1 commit
  24. 16 Dec, 2017 1 commit