1. 30 Jun, 2020 1 commit
  2. 24 Jun, 2020 1 commit
  3. 22 Jun, 2020 2 commits
  4. 18 Jun, 2020 1 commit
  5. 17 Jun, 2020 1 commit
  6. 10 Jun, 2020 1 commit
  7. 07 Jun, 2020 1 commit
  8. 31 May, 2020 1 commit
  9. 24 May, 2020 1 commit
  10. 17 May, 2020 1 commit
  11. 10 May, 2020 1 commit
  12. 09 May, 2020 5 commits
    • Linus Torvalds's avatar
      gcc-10: disable 'restrict' warning for now · adc71920
      Linus Torvalds authored
      gcc-10 now warns about passing aliasing pointers to functions that take
      restricted pointers.
      
      That's actually a great warning, and if we ever start using 'restrict'
      in the kernel, it might be quite useful.  But right now we don't, and it
      turns out that the only thing this warns about is an idiom where we have
      declared a few functions to be "printf-like" (which seems to make gcc
      pick up the restricted pointer thing), and then we print to the same
      buffer that we also use as an input.
      
      And people do that as an odd concatenation pattern, with code like this:
      
          #define sysfs_show_gen_prop(buffer, fmt, ...) \
              snprintf(buffer, PAGE_SIZE, "%s"fmt, buffer, __VA_ARGS__)
      
      where we have 'buffer' as both the destination of the final result, and
      as the initial argument.
      
      Yes, it's a bit questionable.  And outside of the kernel, people do have
      standard declarations like
      
          int snprintf( char *restrict buffer, size_t bufsz,
                        const char *restrict format, ... );
      
      where that output buffer is marked as a restrict pointer that cannot
      alias with any other arguments.
      
      But in the context of the kernel, that 'use snprintf() to concatenate to
      the end result' does work, and the pattern shows up in multiple places.
      And we have not marked our own version of snprintf() as taking restrict
      pointers, so the warning is incorrect for now, and gcc picks it up on
      its own.
      
      If we do start using 'restrict' in the kernel (and it might be a good
      idea if people find places where it matters), we'll need to figure out
      how to avoid this issue for snprintf and friends.  But in the meantime,
      this warning is not useful.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      adc71920
    • Linus Torvalds's avatar
      gcc-10: disable 'stringop-overflow' warning for now · 5a76021c
      Linus Torvalds authored
      This is the final array bounds warning removal for gcc-10 for now.
      
      Again, the warning is good, and we should re-enable all these warnings
      when we have converted all the legacy array declaration cases to
      flexible arrays. But in the meantime, it's just noise.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5a76021c
    • Linus Torvalds's avatar
      gcc-10: disable 'array-bounds' warning for now · 44720996
      Linus Torvalds authored
      This is another fine warning, related to the 'zero-length-bounds' one,
      but hitting the same historical code in the kernel.
      
      Because C didn't historically support flexible array members, we have
      code that instead uses a one-sized array, the same way we have cases of
      zero-sized arrays.
      
      The one-sized arrays come from either not wanting to use the gcc
      zero-sized array extension, or from a slight convenience-feature, where
      particularly for strings, the size of the structure now includes the
      allocation for the final NUL character.
      
      So with a "char name[1];" at the end of a structure, you can do things
      like
      
             v = my_malloc(sizeof(struct vendor) + strlen(name));
      
      and avoid the "+1" for the terminator.
      
      Yes, the modern way to do that is with a flexible array, and using
      'offsetof()' instead of 'sizeof()', and adding the "+1" by hand.  That
      also technically gets the size "more correct" in that it avoids any
      alignment (and thus padding) issues, but this is another long-term
      cleanup thing that will not happen for 5.7.
      
      So disable the warning for now, even though it's potentially quite
      useful.  Having a slew of warnings that then hide more urgent new issues
      is not an improvement.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      44720996
    • Linus Torvalds's avatar
      gcc-10: disable 'zero-length-bounds' warning for now · 5c45de21
      Linus Torvalds authored
      This is a fine warning, but we still have a number of zero-length arrays
      in the kernel that come from the traditional gcc extension.  Yes, they
      are getting converted to flexible arrays, but in the meantime the gcc-10
      warning about zero-length bounds is very verbose, and is hiding other
      issues.
      
      I missed one actual build failure because it was hidden among hundreds
      of lines of warning.  Thankfully I caught it on the second go before
      pushing things out, but it convinced me that I really need to disable
      the new warnings for now.
      
      We'll hopefully be all done with our conversion to flexible arrays in
      the not too distant future, and we can then re-enable this warning.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5c45de21
    • Linus Torvalds's avatar
      Stop the ad-hoc games with -Wno-maybe-initialized · 78a5255f
      Linus Torvalds authored
      We have some rather random rules about when we accept the
      "maybe-initialized" warnings, and when we don't.
      
      For example, we consider it unreliable for gcc versions < 4.9, but also
      if -O3 is enabled, or if optimizing for size.  And then various kernel
      config options disabled it, because they know that they trigger that
      warning by confusing gcc sufficiently (ie PROFILE_ALL_BRANCHES).
      
      And now gcc-10 seems to be introducing a lot of those warnings too, so
      it falls under the same heading as 4.9 did.
      
      At the same time, we have a very straightforward way to _enable_ that
      warning when wanted: use "W=2" to enable more warnings.
      
      So stop playing these ad-hoc games, and just disable that warning by
      default, with the known and straight-forward "if you want to work on the
      extra compiler warnings, use W=123".
      
      Would it be great to have code that is always so obvious that it never
      confuses the compiler whether a variable is used initialized or not?
      Yes, it would.  In a perfect world, the compilers would be smarter, and
      our source code would be simpler.
      
      That's currently not the world we live in, though.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      78a5255f
  13. 03 May, 2020 1 commit
  14. 26 Apr, 2020 1 commit
  15. 19 Apr, 2020 1 commit
  16. 12 Apr, 2020 1 commit
  17. 08 Apr, 2020 4 commits
    • Masahiro Yamada's avatar
      kbuild: support LLVM=1 to switch the default tools to Clang/LLVM · a0d1c951
      Masahiro Yamada authored
      As Documentation/kbuild/llvm.rst implies, building the kernel with a
      full set of LLVM tools gets very verbose and unwieldy.
      
      Provide a single switch LLVM=1 to use Clang and LLVM tools instead
      of GCC and Binutils. You can pass it from the command line or as an
      environment variable.
      
      Please note LLVM=1 does not turn on the integrated assembler. You need
      to pass LLVM_IAS=1 to use it. When the upstream kernel is ready for the
      integrated assembler, I think we can make it default.
      
      We discussed what we need, and we agreed to go with a simple boolean
      flag that switches both target and host tools:
      
        https://lkml.org/lkml/2020/3/28/494
        https://lkml.org/lkml/2020/4/3/43
      
      Some items discussed, but not adopted:
      
      - LLVM_DIR
      
        When multiple versions of LLVM are installed, I just thought supporting
        LLVM_DIR=/path/to/my/llvm/bin/ might be useful.
      
        CC      = $(LLVM_DIR)clang
        LD      = $(LLVM_DIR)ld.lld
          ...
      
        However, we can handle this by modifying PATH. So, we decided to not do
        this.
      
      - LLVM_SUFFIX
      
        Some distributions (e.g. Debian) package specific versions of LLVM with
        naming conventions that use the version as a suffix.
      
        CC      = clang$(LLVM_SUFFIX)
        LD      = ld.lld(LLVM_SUFFIX)
          ...
      
        will allow a user to pass LLVM_SUFFIX=-11 to use clang-11 etc.,
        but the suffixed versions in /usr/bin/ are symlinks to binaries in
        /usr/lib/llvm-#/bin/, so this can also be handled by PATH.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Tested-by: Nathan Chancellor <natechancellor@gmail.com> # build
      Tested-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      a0d1c951
    • Masahiro Yamada's avatar
      kbuild: replace AS=clang with LLVM_IAS=1 · 7e20e47c
      Masahiro Yamada authored
      The 'AS' variable is unused for building the kernel. Only the remaining
      usage is to turn on the integrated assembler. A boolean flag is a better
      fit for this purpose.
      
      AS=clang was added for experts. So, I replaced it with LLVM_IAS=1,
      breaking the backward compatibility.
      Suggested-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      7e20e47c
    • Masahiro Yamada's avatar
      kbuild: link lib-y objects to vmlinux forcibly when CONFIG_MODULES=y · 7273ad2b
      Masahiro Yamada authored
      Kbuild supports not only obj-y but also lib-y to list objects linked to
      vmlinux.
      
      The difference between them is that all the objects from obj-y are
      forcibly linked to vmlinux, whereas the objects from lib-y are linked
      as needed; if there is no user of a lib-y object, it is not linked.
      
      lib-y is intended to list utility functions that may be called from all
      over the place (and may be unused at all), but it is a problem for
      EXPORT_SYMBOL(). Even if there is no call-site in the vmlinux, we need
      to keep exported symbols for the use from loadable modules.
      
      Commit 7f2084fa ("[kbuild] handle exports in lib-y objects reliably")
      worked around it by linking a dummy object, lib-ksyms.o, which contains
      references to all the symbols exported from lib.a in that directory.
      It uses the linker script command, EXTERN. Unfortunately, the meaning of
      EXTERN of ld.lld is different from that of ld.bfd. Therefore, this does
      not work with LD=ld.lld (CBL issue #515).
      
      Anyway, the build rule of lib-ksyms.o is somewhat tricky. So, I want to
      get rid of it.
      
      At first, I was thinking of accumulating lib-y objects into obj-y
      (or even replacing lib-y with obj-y entirely), but the lib-y syntax
      is used beyond the ordinary use in lib/ and arch/*/lib/.
      
      Examples:
      
       - drivers/firmware/efi/libstub/Makefile builds lib.a, which is linked
         into vmlinux in the own way (arm64), or linked to the decompressor
         (arm, x86).
      
       - arch/alpha/lib/Makefile builds lib.a which is linked not only to
         vmlinux, but also to bootloaders in arch/alpha/boot/Makefile.
      
       - arch/xtensa/boot/lib/Makefile builds lib.a for use from
         arch/xtensa/boot/boot-redboot/Makefile.
      
      One more thing, adding everything to obj-y would increase the vmlinux
      size of allnoconfig (or tinyconfig).
      
      For less impact, I tweaked the destination of lib.a at the top Makefile;
      when CONFIG_MODULES=y, lib.a goes to KBUILD_VMLINUX_OBJS, which is
      forcibly linked to vmlinux, otherwise lib.a goes to KBUILD_VMLINUX_LIBS
      as before.
      
      The size impact for normal usecases is quite small since at lease one
      symbol in every lib-y object is eventually called by someone. In case
      you are intrested, here are the figures.
      
      x86_64_defconfig:
      
         text	   data	    bss	    dec	    hex	filename
      19566602 5422072 1589328 26578002 1958c52 vmlinux.before
      19566932 5422104 1589328 26578364 1958dbc vmlinux.after
      
      The case with the biggest impact is allnoconfig + CONFIG_MODULES=y.
      
      ARCH=x86 allnoconfig + CONFIG_MODULES=y:
      
         text	   data	    bss	    dec	    hex	filename
      1175162	 254740	1220608	2650510	 28718e	vmlinux.before
      1177974	 254836	1220608	2653418	 287cea	vmlinux.after
      
      Hopefully this is still not a big deal. The per-file trimming with the
      static library is not so effective after all.
      
      If fine-grained optimization is desired, some architectures support
      CONFIG_LD_DEAD_CODE_DATA_ELIMINATION, which trims dead code per-symbol
      basis. When LTO is supported in mainline, even better optimization will
      be possible.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/515Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      7273ad2b
    • Nathan Chancellor's avatar
      kbuild: Enable -Wtautological-compare · afe956c5
      Nathan Chancellor authored
      Currently, we disable -Wtautological-compare, which in turn disables a
      bunch of more specific tautological comparison warnings that are useful
      for the kernel such as -Wtautological-bitwise-compare. See clang's
      documentation below for the other warnings that are suppressed by
      -Wtautological-compare. Now that all of the major/noisy warnings have
      been fixed, enable -Wtautological-compare so that more issues can be
      caught at build time by various continuous integration setups.
      
      -Wtautological-constant-out-of-range-compare is kept disabled under a
      normal build but visible at W=1 because there are places in the kernel
      where a constant or variable size can change based on the kernel
      configuration. These are not fixed in a clean/concise way and the ones
      I have audited so far appear to be harmless. It is not a subgroup but
      rather just one warning so we do not lose out on much coverage by
      default.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/488
      Link: http://releases.llvm.org/10.0.0/tools/clang/docs/DiagnosticsReference.html#wtautological-compare
      Link: https://bugs.llvm.org/show_bug.cgi?id=42666Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      afe956c5
  18. 31 Mar, 2020 1 commit
  19. 29 Mar, 2020 5 commits
    • Linus Torvalds's avatar
      Linux 5.6 · 7111951b
      Linus Torvalds authored
      7111951b
    • David Engraf's avatar
      kbuild: add outputmakefile to no-dot-config-targets · 4623980d
      David Engraf authored
      The target outputmakefile is used to generate a Makefile
      for out-of-tree builds and does not depend on the kernel
      configuration.
      Signed-off-by: default avatarDavid Engraf <david.engraf@sysgo.com>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      4623980d
    • Masahiro Yamada's avatar
      kbuild: remove AS variable · aa824e0c
      Masahiro Yamada authored
      As commit 5ef87263 ("kbuild: get rid of misleading $(AS) from
      documents") noted, we rarely use $(AS) directly in the kernel build.
      
      Now that the only/last user of $(AS) in drivers/net/wan/Makefile was
      converted to $(CC), $(AS) is no longer used in the build process.
      
      You can still pass in AS=clang, which is just a switch to turn on
      the LLVM integrated assembler.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Tested-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      aa824e0c
    • Masahiro Yamada's avatar
      kbuild: add comment about grouped target · f463c351
      Masahiro Yamada authored
      GNU Make commit 8c888d95f618 ("[SV 8297] Implement "grouped targets"
      for explicit rules.") added the '&:' syntax.
      
      I think '&:' is a perfect fit here, but we cannot use it any time
      soon. Just add a TODO comment.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      f463c351
    • Masahiro Yamada's avatar
      kbuild: add -Wall to KBUILD_HOSTCXXFLAGS · 735aab1e
      Masahiro Yamada authored
      Add -Wall to catch more warnings for C++ host programs.
      
      When I submitted the previous version, the 0-day bot reported
      -Wc++11-compat warnings for old GCC:
      
        HOSTCXX -fPIC scripts/gcc-plugins/latent_entropy_plugin.o
      In file included from /usr/lib/gcc/x86_64-linux-gnu/4.8/plugin/include/tm.h:28:0,
                       from scripts/gcc-plugins/gcc-common.h:15,
                       from scripts/gcc-plugins/latent_entropy_plugin.c:78:
      /usr/lib/gcc/x86_64-linux-gnu/4.8/plugin/include/config/elfos.h:102:21: warning: C++11 requires a space between string literal and macro [-Wc++11-compat]
          fprintf ((FILE), "%s"HOST_WIDE_INT_PRINT_UNSIGNED"\n",\
                           ^
      /usr/lib/gcc/x86_64-linux-gnu/4.8/plugin/include/config/elfos.h:170:24: warning: C++11 requires a space between string literal and macro [-Wc++11-compat]
             fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n",  \
                              ^
      In file included from /usr/lib/gcc/x86_64-linux-gnu/4.8/plugin/include/tm.h:42:0,
                       from scripts/gcc-plugins/gcc-common.h:15,
                       from scripts/gcc-plugins/latent_entropy_plugin.c:78:
      /usr/lib/gcc/x86_64-linux-gnu/4.8/plugin/include/defaults.h:126:24: warning: C++11 requires a space between string literal and macro [-Wc++11-compat]
             fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n",  \
                              ^
      
      The source of the warnings is in the plugin headers, so we have no
      control of it. I just suppressed them by adding -Wno-c++11-compat to
      scripts/gcc-plugins/Makefile.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      735aab1e
  20. 25 Mar, 2020 1 commit
  21. 23 Mar, 2020 1 commit
  22. 19 Mar, 2020 1 commit
  23. 15 Mar, 2020 1 commit
  24. 13 Mar, 2020 3 commits
    • Masahiro Yamada's avatar
      kbuild: allow to run dt_binding_check without kernel configuration · 9dffecc1
      Masahiro Yamada authored
      The dt_binding_check target is located outside of the
      'ifneq ($(dtstree),) ... endif' block.
      
      So, you can run 'make dt_binding_check' on any architecture.
      This makes a perfect sense because the dt-schema is arch-agnostic.
      
      The only one problem I see is that scripts/dtc/dtc is not always built.
      For example, ARCH=x86 defconfig does not define CONFIG_DTC. Kbuild
      descends into scripts/dtc/ with doing nothing. Then, it fails to build
      *.example.dt.yaml files.
      
      Let's build scripts/dtc/dtc forcibly when running dt_binding_check.
      
      The dt-schema does not depend on any CONFIG option either, so you
      should be able to run dt_binding_check without the .config file.
      
      Going forward, you can directly run 'make dt_binding_check' in a
      pristine source tree.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      9dffecc1
    • Masahiro Yamada's avatar
      kbuild: allow to run dt_binding_check and dtbs_check in a single command · e10c4321
      Masahiro Yamada authored
      Since commit 93512dad ("dt-bindings: Improve validation build error
      handling"), 'make dtbs_check' does not validate the schema fully.
      
      If you want to check everything, you need to run two commands separately.
      
        $ make ARCH=arm dt_binding_check
        $ make ARCH=arm dtbs_check
      
      They are exclusive each other, so you cannot do like this:
      
        $ make ARCH=arm dt_binding_check dtbs_check
      
      In this case, dt-doc-validate and dt-extract-example are skipped
      because CHECK_DTBS is set.
      
      Let's make it possible to run these two targets in a single command.
      It will be useful for schema writers.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      e10c4321
    • Masahiro Yamada's avatar
      kbuild: avoid concurrency issue in parallel building dtbs and dtbs_check · b5154bf6
      Masahiro Yamada authored
      'make dtbs_check' checks the shecma in addition to building *.dtb files,
      in other words, 'make dtbs_check' is a super-set of 'make dtbs'.
      So, you do not have to do 'make dtbs dtbs_check', but I want to keep
      the build system as robust as possible in any use.
      
      Currently, 'dtbs' and 'dtbs_check' are independent of each other.
      In parallel building, two threads descend into arch/*/boot/dts/,
      one for dtbs and the other for dtbs_check, then end up with building
      the same DTB simultaneously.
      
      This commit fixes the concurrency issue. Otherwise, I see build errors
      like follows:
      
      $ make ARCH=arm64 defconfig
      $ make -j16 ARCH=arm64 DT_SCHEMA_FILES=Documentation/devicetree/bindings/arm/psci.yaml dtbs dtbs_check
        <snip>
        DTC     arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dtb
        DTC     arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtb
        DTC     arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb
        DTC     arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb
        DTC     arch/arm64/boot/dts/freescale/imx8mn-evk.dtb
        DTC     arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb
        DTC     arch/arm64/boot/dts/zte/zx296718-pcbox.dtb
        DTC     arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dt.yaml
        DTC     arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dtb
        DTC     arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dtb
        DTC     arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dtb
        DTC     arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-inx.dtb
        DTC     arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb
        CHECK   arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dt.yaml
      fixdep: error opening file: arch/arm64/boot/dts/allwinner/.sun50i-h6-orangepi-lite2.dtb.d: No such file or directory
      make[2]: *** [scripts/Makefile.lib:296: arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb] Error 2
      make[2]: *** Deleting file 'arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb'
      make[2]: *** Waiting for unfinished jobs....
        DTC     arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-kd.dtb
        DTC     arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dtb
        DTC     arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dtb
        DTC     arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dtb
      fixdep: parse error; no targets found
      make[2]: *** [scripts/Makefile.lib:296: arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb] Error 1
      make[2]: *** Deleting file 'arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb'
      make[1]: *** [scripts/Makefile.build:505: arch/arm64/boot/dts/allwinner] Error 2
      make[1]: *** Waiting for unfinished jobs....
        DTC     arch/arm64/boot/dts/renesas/r8a77951-salvator-xs.dtb
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      b5154bf6
  25. 11 Mar, 2020 1 commit
  26. 09 Mar, 2020 1 commit