1. 29 Sep, 2018 1 commit
  2. 26 Sep, 2018 2 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.18.10 · 18334848
      Greg Kroah-Hartman authored
    • Masahiro Yamada's avatar
      kbuild: do not update config when running install targets · e8b53e57
      Masahiro Yamada authored
      [ Upstream commit d7942413 ]
      "make syncconfig" is automatically invoked when any of the following
       - .config is updated
       - any of Kconfig files is updated
       - any of environment variables referenced in Kconfig is changed
      Then, it updates configuration files such as include/config/auto.conf
      include/generated/autoconf.h, etc.
      Even install targets (install, modules_install, etc.) are no exception.
      However, they should never ever modify the source tree.  Install
      targets are often run with root privileges.  Once those configuration
      files are owned by root, "make mrproper" would end up with permission
      Install targets should just copy things blindly.  They should not care
      whether the configuration is up-to-date or not.  This makes more sense
      because we are interested in the configuration that was used in the
      previous kernel building.
      This issue has existed since before, but rarely happened.  I expect
      more chance where people are hit by this; with the new Kconfig syntax
      extension, the .config now contains the compiler information.  If you
      cross-compile the kernel with CROSS_COMPILE, but forget to pass it
      for "make install", you meet "any of environment variables referenced
      in Kconfig is changed" because $(CC) is referenced in Kconfig.
      Another scenario is the compiler upgrade before the installation.
      Install targets need the configuration.  "make modules_install" refer
      to CONFIG_MODULES etc.  "make dtbs_install" also needs CONFIG_ARCH_*
      to decide which dtb files to install.  However, the auto-update of
      the configuration files should be avoided.  We already do this for
      external modules.
      Now, Make targets are categorized into 3 groups:
      [1] Do not need the kernel configuration at all
          help, coccicheck, headers_install etc.
      [2] Need the latest kernel configuration
          If new config options are added, Kconfig will show prompt to
          ask user's selection.
          Build targets such as vmlinux, in-kernel modules are the cases.
      [3] Need the kernel configuration, but do not want to update it
          Install targets except headers_install, and external modules
          are the cases.
      Signed-off-by: default 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>
  3. 19 Sep, 2018 1 commit
  4. 15 Sep, 2018 1 commit
  5. 09 Sep, 2018 1 commit
  6. 05 Sep, 2018 2 commits
  7. 24 Aug, 2018 1 commit
  8. 22 Aug, 2018 1 commit
  9. 18 Aug, 2018 1 commit
  10. 17 Aug, 2018 1 commit
  11. 15 Aug, 2018 1 commit
  12. 12 Aug, 2018 1 commit
  13. 05 Aug, 2018 1 commit
  14. 29 Jul, 2018 1 commit
  15. 22 Jul, 2018 1 commit
  16. 15 Jul, 2018 1 commit
  17. 12 Jul, 2018 1 commit
  18. 08 Jul, 2018 1 commit
  19. 06 Jul, 2018 1 commit
  20. 01 Jul, 2018 1 commit
  21. 28 Jun, 2018 1 commit
  22. 24 Jun, 2018 1 commit
  23. 16 Jun, 2018 1 commit
  24. 14 Jun, 2018 1 commit
    • Linus Torvalds's avatar
      Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables · 050e9baa
      Linus Torvalds authored
      The changes to automatically test for working stack protector compiler
      support in the Kconfig files removed the special STACKPROTECTOR_AUTO
      option that picked the strongest stack protector that the compiler
      That was all a nice cleanup - it makes no sense to have the AUTO case
      now that the Kconfig phase can just determine the compiler support
      It also meant that doing "make oldconfig" would now _disable_ the strong
      stackprotector if you had AUTO enabled, because in a legacy config file,
      the sane stack protector configuration would look like
      and when you ran this through "make oldconfig" with the Kbuild changes,
      it would ask you about the regular CONFIG_CC_STACKPROTECTOR (that had
      been renamed from CONFIG_CC_STACKPROTECTOR_REGULAR to just
      CONFIG_CC_STACKPROTECTOR), but it would think that the STRONG version
      used to be disabled (because it was really enabled by AUTO), and would
      disable it in the new config, resulting in:
      That's dangerously subtle - people could suddenly find themselves with
      the weaker stack protector setup without even realizing.
      The solution here is to just rename not just the old RECULAR stack
      protector option, but also the strong one.  This does that by just
      removing the CC_ prefix entirely for the user choices, because it really
      is not about the compiler support (the compiler support now instead
      automatially impacts _visibility_ of the options to users).
      This results in "make oldconfig" actually asking the user for their
      choice, so that we don't have any silent subtle security model changes.
      The end result would generally look like this:
      where the "CC_" versions really are about internal compiler
      infrastructure, not the user selections.
      Acked-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  25. 11 Jun, 2018 1 commit
    • Masahiro Yamada's avatar
      kcov: test compiler capability in Kconfig and correct dependency · 5aadfdeb
      Masahiro Yamada authored
      As Documentation/kbuild/kconfig-language.txt notes, 'select' should be
      be used with care - it forces a lower limit of another symbol, ignoring
      the dependency.  Currently, KCOV can select GCC_PLUGINS even if arch
      does not select HAVE_GCC_PLUGINS.  This could cause the unmet direct
      Now that Kconfig can test compiler capability, let's handle this in a
      more sophisticated way.
      There are two ways to enable KCOV; use the compiler that natively
      supports -fsanitize-coverage=trace-pc, or build the SANCOV plugin if
      the compiler has ability to build GCC plugins.  Hence, the correct
      dependency for KCOV is:
        depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS
      You do not need to build the SANCOV plugin if the compiler already
      supports -fsanitize-coverage=trace-pc.  Hence, the select should be:
      With this, GCC_PLUGIN_SANCOV is selected only when necessary, so
      scripts/Makefile.gcc-plugins can be cleaner.
      I also cleaned up Kconfig and scripts/Makefile.kcov as well.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
  26. 08 Jun, 2018 2 commits
    • Masahiro Yamada's avatar
      stack-protector: test compiler capability in Kconfig and drop AUTO mode · 2a61f474
      Masahiro Yamada authored
      Move the test for -fstack-protector(-strong) option to Kconfig.
      If the compiler does not support the option, the corresponding menu
      is automatically hidden.  If STRONG is not supported, it will fall
      back to REGULAR.  If REGULAR is not supported, it will be disabled.
      This means, AUTO is implicitly handled by the dependency solver of
      Kconfig, hence removed.
      I also turned the 'choice' into only two boolean symbols.  The use of
      'choice' is not a good idea here, because all of all{yes,mod,no}config
      would choose the first visible value, while we want allnoconfig to
      disable as many features as possible.
      X86 has additional shell scripts in case the compiler supports those
      options, but generates broken code.  I added CC_HAS_SANE_STACKPROTECTOR
      to test this.  I had to add -m32 to gcc-x86_32-has-stack-protector.sh
      to make it work correctly.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
    • Masahiro Yamada's avatar
      kbuild: fix endless syncconfig in case arch Makefile sets CROSS_COMPILE · 315bab4e
      Masahiro Yamada authored
      Commit 21c54b77 ("kconfig: show compiler version text in the top
      comment") was intended to detect the compiler upgrade, but Geert
      reported a breakage on the m68k build.
      The compiler upgrade is detected by the change of the environment
      variable, CC_VERSION_TEXT, which contains the first line of the output
      from $(CC) --version.  Currently, this works well when CROSS_COMPILE
      is given via the environment variable or the Make command line.
      However, some architectures such as m68k can specify CROSS_COMPILE
      from arch/$(SRCARCH)/Makefile as well.  In this case, "make ARCH=m68k"
      ends up with endless syncconfig loop.
        $ make ARCH=m68k defconfig
        *** Default configuration is based on 'multi_defconfig'
        # configuration written to .config
        $ make ARCH=m68k
        scripts/kconfig/conf  --syncconfig Kconfig
        scripts/kconfig/conf  --syncconfig Kconfig
        scripts/kconfig/conf  --syncconfig Kconfig
        scripts/kconfig/conf  --syncconfig Kconfig
      Things are happening like this:
      Because arch/$(SRCARCH)/Makefile is included after CC_VERSION_TEXT
      is set, it contains the host compiler version in the defconfig phase.
      To create or update auto.conf, the following line is triggered:
      include/config/%.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd
              $(Q)$(MAKE) -f $(srctree)/Makefile syncconfig
      This recurses the top Makefile after arch/$(SRCARCH)/Makefile is
      included.  CROSS_COMPILE is set to a m68k toolchain prefix and
      exported to the recursed Make.  Then, syncconfig is invoked with
      the target compiler version in CC_VERSION_TEXT.
      The Make will restart because auto.conf and auto.conf.cmd have been
      updated.  At this point, CROSS_COMPILE is reset, so CC_VERSION_TEXT
      is set to the host compiler version again.  Then, syncconfig is
      triggered due to the change of CC_VERSION_TEXT.  This loop continues
      To fix this problem, $(CC_VERSION_TEXT) must be evaluated only after
      arch/$(SRCARCH)/Makefile.  Setting it earlier is OK as long as it is
      defined by using the '=' operator instead of ':='.
      For the defconfig phase, $(CC_VERSION_TEXT) is evaluated when Kbuild
      descends into scripts/kconfig/, so it contains the target compiler
      version correctly.
      include/config/auto.conf.cmd references $(CC_VERSION_TEXT) as well,
      so it must be included after arch/$(SRCARCH)/Makefile.
      Fixes: 21c54b77 ("kconfig: show compiler version text in the top comment")
      Reported-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Tested-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
  27. 05 Jun, 2018 1 commit
  28. 03 Jun, 2018 1 commit
  29. 01 Jun, 2018 1 commit
  30. 29 May, 2018 2 commits
  31. 28 May, 2018 5 commits
    • Masahiro Yamada's avatar
      kconfig: show compiler version text in the top comment · 21c54b77
      Masahiro Yamada authored
      The kernel configuration phase is now tightly coupled with the compiler
      in use.  It will be nice to show the compiler information in Kconfig.
      The compiler information will be displayed like this:
        $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- config
        scripts/kconfig/conf  --oldaskconfig Kconfig
        * Linux/arm64 4.16.0-rc1 Kernel Configuration
        * Compiler: aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011
        * General setup
        Compile also drivers which will not load (COMPILE_TEST) [N/y/?]
      If you use GUI methods such as menuconfig, it will be displayed in the
      top menu.
      This is simply implemented by using the 'comment' statement.  So, it
      will be saved into the .config file as well.
      This commit has a very important meaning.  If the compiler is upgraded,
      Kconfig must be re-run since different compilers have different sets
      of supported options.
      All referenced environments are written to include/config/auto.conf.cmd
      so that any environment change triggers syncconfig, and prompt the user
      to input new values if needed.
      With this commit, something like follows will be added to
        ifneq "$(CC_VERSION_TEXT)" "aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011"
        include/config/auto.conf: FORCE
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
    • 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
      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>
    • 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
                default "My tools: CC=$(CC), AS=$(AS), CPP=$(CPP)"
        $ 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>
    • 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] 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.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
    • 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>
  32. 27 May, 2018 1 commit