1. 10 Sep, 2018 1 commit
  2. 02 Sep, 2018 1 commit
  3. 31 Aug, 2018 1 commit
  4. 26 Aug, 2018 1 commit
  5. 23 Aug, 2018 2 commits
  6. 22 Aug, 2018 1 commit
  7. 20 Aug, 2018 1 commit
  8. 16 Aug, 2018 3 commits
  9. 12 Aug, 2018 1 commit
  10. 09 Aug, 2018 1 commit
  11. 07 Aug, 2018 1 commit
  12. 05 Aug, 2018 1 commit
  13. 29 Jul, 2018 1 commit
  14. 28 Jul, 2018 1 commit
  15. 25 Jul, 2018 4 commits
    • Masahiro Yamada's avatar
      kbuild: remove auto.conf from prerequisite of phony targets · 2063945f
      Masahiro Yamada authored
      The top-level Makefile adds include/config/auto.conf as
      prerequisites of 'scripts', 'prepare1', etc.
      They were needed to terminate the build when include/config/auto.conf
      is missing.
      Now that the inclusion of include/config/auto.conf is mandatory
      in the top-level Makefile if dot-config is 1 (Note 'include' directive
      is used instead of '-include').
      Make terminates the build by itself if it fails to create or update
      include/config/auto.conf so we are sure that include/config/auto.conf
      exists in the very first stage of make.
      I am still keeping include/config/auto.conf as the prerequisite of
      %/modules.builtin because modules.builtin is a real file.  According
      to commit a6c36632 ("kbuild: Do not unnecessarily regenerate
      modules.builtin"), it is intentional to compare time-stamps between
      %/modules.builtin and include/config/auto.conf .  I moved tristate.conf
      here because it is only included from scripts/Makefile.modbuiltin.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
    • Masahiro Yamada's avatar
      kbuild: do not update config for 'make kernelrelease' · a29d4d8c
      Masahiro Yamada authored
      'make kernelrelease' depends on CONFIG_LOCALVERSION(_AUTO), but
      for the same reason as install targets, we do not want to update
      the configuration just for printing the kernelrelease string.
      This is likely to happen when you compiled the kernel with
      CROSS_COMPILE, but forget to pass it to 'make kernelrelease'.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
    • Masahiro Yamada's avatar
      kbuild: do not update config when running install targets · d7942413
      Masahiro Yamada authored
      "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>
    • Masahiro Yamada's avatar
      kbuild: use 'include' directive to load auto.conf from top Makefile · 0a16d2e8
      Masahiro Yamada authored
      When you build targets that require the kernel configuration, dot-config
      is set to 1, then the top-level Makefile includes auto.conf.  However,
      Make considers its inclusion is optional because the '-include' directive
      is used here.
      If a necessary configuration file is missing for the external module
      building, the following error message is displayed:
        ERROR: Kernel configuration is invalid.
               include/generated/autoconf.h or include/config/auto.conf are missing.
               Run 'make oldconfig && make prepare' on kernel src to fix it.
      However, Make still continues building; /bin/false let the creation of
      'include/config/auto.config' fail, but Make can ignore the error since
      it is included by the '-include' directive.
      I guess the reason of using '-include' directive was to suppress
      the warning when you build the kernel from a pristine source tree:
        Makefile:605: include/config/auto.conf: No such file or directory
      The previous commit made sure include/config/auto.conf exists after
      the 'make *config' stage.  Now, we can use the 'include' directive
      without showing the warning.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
  16. 22 Jul, 2018 1 commit
  17. 17 Jul, 2018 5 commits
  18. 15 Jul, 2018 1 commit
  19. 12 Jul, 2018 1 commit
  20. 08 Jul, 2018 1 commit
  21. 06 Jul, 2018 1 commit
  22. 01 Jul, 2018 1 commit
  23. 28 Jun, 2018 1 commit
  24. 24 Jun, 2018 1 commit
  25. 16 Jun, 2018 1 commit
  26. 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>
  27. 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>
  28. 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>
  29. 05 Jun, 2018 1 commit