1. 28 May, 2018 4 commits
    • Masahiro Yamada's avatar
      kconfig: replace $(UNAME_RELEASE) with function call · 2972666a
      Masahiro Yamada authored
      Now that 'shell' function is supported, this can be self-contained in
      Kconfig.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarUlf Magnusson <ulfalizer@gmail.com>
      2972666a
    • Masahiro Yamada's avatar
      kconfig: reference environment variables directly and remove 'option env=' · 104daea1
      Masahiro Yamada authored
      To get access to environment variables, Kconfig needs to define a
      symbol using "option env=" syntax.  It is tedious to add a symbol entry
      for each environment variable given that we need to define much more
      such as 'CC', 'AS', 'srctree' etc. to evaluate the compiler capability
      in Kconfig.
      
      Adding '$' for symbol references is grammatically inconsistent.
      Looking at the code, the symbols prefixed with 'S' are expanded by:
       - conf_expand_value()
         This is used to expand 'arch/$ARCH/defconfig' and 'defconfig_list'
       - sym_expand_string_value()
         This is used to expand strings in 'source' and 'mainmenu'
      
      All of them are fixed values independent of user configuration.  So,
      they can be changed into the direct expansion instead of symbols.
      
      This change makes the code much cleaner.  The bounce symbols 'SRCARCH',
      'ARCH', 'SUBARCH', 'KERNELVERSION' are gone.
      
      sym_init() hard-coding 'UNAME_RELEASE' is also gone.  'UNAME_RELEASE'
      should be replaced with an environment variable.
      
      ARCH_DEFCONFIG is a normal symbol, so it should be simply referenced
      without '$' prefix.
      
      The new syntax is addicted by Make.  The variable reference needs
      parentheses, like $(FOO), but you can omit them for single-letter
      variables, like $F.  Yet, in Makefiles, people tend to use the
      parenthetical form for consistency / clarification.
      
      At this moment, only the environment variable is supported, but I will
      extend the concept of 'variable' later on.
      
      The variables are expanded in the lexer so we can simplify the token
      handling on the parser side.
      
      For example, the following code works.
      
      [Example code]
      
        config MY_TOOLCHAIN_LIST
                string
                default "My tools: CC=$(CC), AS=$(AS), CPP=$(CPP)"
      
      [Result]
      
        $ make -s alldefconfig && tail -n 1 .config
        CONFIG_MY_TOOLCHAIN_LIST="My tools: CC=gcc, AS=as, CPP=gcc -E"
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      104daea1
    • Masahiro Yamada's avatar
      kbuild: remove CONFIG_CROSS_COMPILE support · f1089c92
      Masahiro Yamada authored
      Kbuild provides a couple of ways to specify CROSS_COMPILE:
      
      [1] Command line
      [2] Environment
      [3] arch/*/Makefile (only some architectures)
      [4] CONFIG_CROSS_COMPILE
      
      [4] is problematic for the compiler capability tests in Kconfig.
      CONFIG_CROSS_COMPILE allows users to change the compiler prefix from
      'make menuconfig', etc.  It means, the compiler options would have
      to be all re-calculated everytime CONFIG_CROSS_COMPILE is changed.
      
      To avoid complexity and performance issues, I'd like to evaluate
      the shell commands statically, i.e. only parsing Kconfig files.
      
      I guess the majority is [1] or [2].  Currently, there are only
      5 defconfig files that specify CONFIG_CROSS_COMPILE.
        arch/arm/configs/lpc18xx_defconfig
        arch/hexagon/configs/comet_defconfig
        arch/nds32/configs/defconfig
        arch/openrisc/configs/or1ksim_defconfig
        arch/openrisc/configs/simple_smp_defconfig
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      f1089c92
    • Masahiro Yamada's avatar
      kbuild: remove kbuild cache · e08d6de4
      Masahiro Yamada authored
      The kbuild cache was introduced to remember the result of shell
      commands, some of which are expensive to compute, such as
      $(call cc-option,...).
      
      However, this turned out not so clever as I had first expected.
      Actually, it is problematic.  For example, "$(CC) -print-file-name"
      is cached.  If the compiler is updated, the stale search path causes
      build error, which is difficult to figure out.  Another problem
      scenario is cache files could be touched while install targets are
      running under the root permission.  We can patch them if desired,
      but the build infrastructure is getting uglier and uglier.
      
      Now, we are going to move compiler flag tests to the configuration
      phase.  If this is completed, the result of compiler tests will be
      naturally cached in the .config file.  We will not have performance
      issues of incremental building since this testing only happens at
      Kconfig time.
      
      To start this work with a cleaner code base, remove the kbuild
      cache first.
      
      Revert the following commits:
      Commit 9a234a2e ("kbuild: create directory for make cache only when necessary")
      Commit e17c400a ("kbuild: shrink .cache.mk when it exceeds 1000 lines")
      Commit 4e562071 ("kbuild: Cache a few more calls to the compiler")
      Commit 3298b690 ("kbuild: Add a cache for generated variables")
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      e08d6de4
  2. 27 May, 2018 1 commit
  3. 20 May, 2018 1 commit
  4. 17 May, 2018 2 commits
  5. 13 May, 2018 1 commit
  6. 07 May, 2018 1 commit
  7. 29 Apr, 2018 1 commit
  8. 23 Apr, 2018 1 commit
  9. 16 Apr, 2018 1 commit
  10. 07 Apr, 2018 4 commits
    • Masahiro Yamada's avatar
      kbuild: use -fmacro-prefix-map to make __FILE__ a relative path · a73619a8
      Masahiro Yamada authored
      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: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      a73619a8
    • Masahiro Yamada's avatar
      kbuild: rename *-asn1.[ch] to *.asn1.[ch] · 4fa8bc94
      Masahiro Yamada authored
      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: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      4fa8bc94
    • Masahiro Yamada's avatar
      kbuild: clean up *-asn1.[ch] patterns from top-level Makefile · 3ca3273e
      Masahiro Yamada authored
      Clean up these patterns from the top Makefile to omit 'clean-files'
      in each Makefile.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      3ca3273e
    • Masahiro Yamada's avatar
      kbuild: clean up *.lex.c and *.tab.[ch] patterns from top-level Makefile · 9a8dfb39
      Masahiro Yamada authored
      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: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarFrank Rowand <frowand.list@gmail.com>
      9a8dfb39
  11. 01 Apr, 2018 1 commit
  12. 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
  13. 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
  14. 20 Mar, 2018 1 commit
  15. 19 Mar, 2018 1 commit
  16. 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
  17. 12 Mar, 2018 1 commit
  18. 04 Mar, 2018 1 commit
  19. 02 Mar, 2018 1 commit
  20. 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
  21. 26 Feb, 2018 1 commit