1. 16 4月, 2018 1 次提交
  2. 07 4月, 2018 4 次提交
    • M
      kbuild: use -fmacro-prefix-map to make __FILE__ a relative path · a73619a8
      Masahiro Yamada 提交于
      The __FILE__ macro is used everywhere in the kernel to locate the file
      printing the log message, such as WARN_ON(), etc.  If the kernel is
      built out of tree, this can be a long absolute path, like this:
      
        WARNING: CPU: 1 PID: 1 at /path/to/build/directory/arch/arm64/kernel/foo.c:...
      
      This is because Kbuild runs in the objtree instead of the srctree,
      then __FILE__ is expanded to a file path prefixed with $(srctree)/.
      
      Commit 9da0763b ("kbuild: Use relative path when building in a
      subdir of the source tree") improved this to some extent; $(srctree)
      becomes ".." if the objtree is a child of the srctree.
      
      For other cases of out-of-tree build, __FILE__ is still the absolute
      path.  It also means the kernel image depends on where it was built.
      
      A brand-new option from GCC, -fmacro-prefix-map, solves this problem.
      If your compiler supports it, __FILE__ is the relative path from the
      srctree regardless of O= option.  This provides more readable log and
      more reproducible builds.
      
      Please note __FILE__ is always an absolute path for external modules.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      a73619a8
    • M
      kbuild: rename *-asn1.[ch] to *.asn1.[ch] · 4fa8bc94
      Masahiro Yamada 提交于
      Our convention is to distinguish file types by suffixes with a period
      as a separator.
      
      *-asn1.[ch] is a different pattern from other generated sources such
      as *.lex.c, *.tab.[ch], *.dtb.S, etc.  More confusing, files with
      '-asn1.[ch]' are generated files, but '_asn1.[ch]' are checked-in
      files:
        net/netfilter/nf_conntrack_h323_asn1.c
        include/linux/netfilter/nf_conntrack_h323_asn1.h
        include/linux/sunrpc/gss_asn1.h
      
      Rename generated files to *.asn1.[ch] for consistency.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      4fa8bc94
    • M
      kbuild: clean up *-asn1.[ch] patterns from top-level Makefile · 3ca3273e
      Masahiro Yamada 提交于
      Clean up these patterns from the top Makefile to omit 'clean-files'
      in each Makefile.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      3ca3273e
    • M
      kbuild: clean up *.lex.c and *.tab.[ch] patterns from top-level Makefile · 9a8dfb39
      Masahiro Yamada 提交于
      Files suffixed by .lex.c, .tab.[ch] are generated lexers, parsers,
      respectively.  Clean them up globally from the top Makefile.
      
      Some of the final host programs those lexer/parser are linked into
      are necessary for building external modules, but the intermediates
      are unneeded.  They can be cleaned away by 'make clean' instead of
      'make mrproper'.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NFrank Rowand <frowand.list@gmail.com>
      9a8dfb39
  3. 02 4月, 2018 1 次提交
  4. 26 3月, 2018 11 次提交
    • L
      Linux 4.16-rc7 · 3eb2ce82
      Linus Torvalds 提交于
      3eb2ce82
    • M
      kbuild: add PYTHON2 and PYTHON3 variables · e9781b52
      Masahiro Yamada 提交于
      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: NMasahiro Yamada <yamada.masahiro@socionext.com>
      e9781b52
    • M
      kconfig: rename silentoldconfig to syncconfig · 911a91c3
      Masahiro Yamada 提交于
      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: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NUlf Magnusson <ulfalizer@gmail.com>
      911a91c3
    • M
      kbuild: link vmlinux only once for CONFIG_TRIM_UNUSED_KSYMS · 3fdc7d3f
      Masahiro Yamada 提交于
      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: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NNicolas Pitre <nico@linaro.org>
      3fdc7d3f
    • M
      kbuild: move include/config/ksym/* to include/ksym/* · fbfa9be9
      Masahiro Yamada 提交于
      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: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NNicolas Pitre <nico@linaro.org>
      fbfa9be9
    • M
      kbuild: move CONFIG_TRIM_UNUSED_KSYMS code unneeded for external module · 1f50b80a
      Masahiro Yamada 提交于
      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: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NNicolas Pitre <nico@linaro.org>
      1f50b80a
    • M
      kbuild: restore autoksyms.h touch to the top Makefile · 07a422bb
      Masahiro Yamada 提交于
      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: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NNicolas Pitre <nico@linaro.org>
      07a422bb
    • M
      kbuild: move 'scripts' target below · d8821622
      Masahiro Yamada 提交于
      Just a trivial change to prepare for the next commit.
      This target is still invisible from external module building.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      d8821622
    • M
      kbuild: clear LDFLAGS in the top Makefile · ce99d0bf
      Masahiro Yamada 提交于
      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: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NNicolas Pitre <nico@linaro.org>
      ce99d0bf
    • M
      kbuild: process mixture of clean/build targets one by one · 22340a06
      Masahiro Yamada 提交于
      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: NMasahiro Yamada <yamada.masahiro@socionext.com>
      22340a06
    • N
      kbuild: rename built-in.o to built-in.a · f49821ee
      Nicholas Piggin 提交于
      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: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      f49821ee
  5. 21 3月, 2018 2 次提交
    • S
      kbuild: set no-integrated-as before incl. arch Makefile · 0f0e8de3
      Stefan Agner 提交于
      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: NStefan Agner <stefan@agner.ch>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      0f0e8de3
    • D
      kbuild: disable clang's default use of -fmerge-all-constants · 87e0d4f0
      Daniel Borkmann 提交于
      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: NPrasad Sodagudi <psodagud@codeaurora.org>
      Signed-off-by: NDaniel 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: NPrasad Sodagudi <psodagud@codeaurora.org>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      87e0d4f0
  6. 20 3月, 2018 1 次提交
  7. 19 3月, 2018 1 次提交
  8. 16 3月, 2018 1 次提交
    • A
      arch: remove tile port · bb9d8126
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      bb9d8126
  9. 12 3月, 2018 1 次提交
  10. 05 3月, 2018 1 次提交
  11. 02 3月, 2018 1 次提交
  12. 01 3月, 2018 2 次提交
    • L
      kbuild: disable sparse warnings about unknown attributes · 6c49f359
      Luc Van Oostenryck 提交于
      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: NLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Acked-by: NRandy Dunlap <rdunlap@infradead.org>
      Tested-by: NRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      6c49f359
    • U
      Makefile: Fix lying comment re. silentoldconfig · 61277981
      Ulf Magnusson 提交于
      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: NUlf Magnusson <ulfalizer@gmail.com>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      61277981
  13. 26 2月, 2018 1 次提交
  14. 21 2月, 2018 1 次提交
  15. 19 2月, 2018 1 次提交
  16. 12 2月, 2018 1 次提交
  17. 07 2月, 2018 5 次提交
  18. 29 1月, 2018 1 次提交
  19. 22 1月, 2018 1 次提交
  20. 15 1月, 2018 1 次提交
  21. 08 1月, 2018 1 次提交