1. 01 Nov, 2020 1 commit
  2. 29 Oct, 2020 1 commit
  3. 17 Oct, 2020 1 commit
  4. 14 Oct, 2020 1 commit
  5. 07 Oct, 2020 1 commit
  6. 01 Oct, 2020 1 commit
  7. 26 Sep, 2020 1 commit
  8. 23 Sep, 2020 1 commit
  9. 17 Sep, 2020 2 commits
    • Greg Kroah-Hartman's avatar
    • Josh Poimboeuf's avatar
      Revert "kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled" · fdbbeae2
      Josh Poimboeuf authored
      [ Upstream commit 318af7b80b6a6751520cf2b71edb8c45abb9d9d8 ]
      Use of the new -flive-patching flag was introduced with the following
        43bd3a95 ("kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled")
      This flag has several drawbacks:
      - It disables some optimizations, so it can have a negative effect on
      - According to the GCC documentation it's not compatible with LTO, which
        will become a compatibility issue as LTO support gets upstreamed in
        the kernel.
      - It was intended to be used for source-based patch generation tooling,
        as opposed to binary-based patch generation tooling (e.g.,
        kpatch-build).  It probably should have at least been behind a
        separate config option so as not to negatively affect other livepatch
      - Clang doesn't have the flag, so as far as I can tell, this method of
        generating patches is incompatible with Clang, which like LTO is
        becoming more mainstream.
      - It breaks GCC's implicit noreturn detection for local functions.  This
        is the cause of several "unreachable instruction" objtool warnings.
      - The broken noreturn detection is an obvious GCC regression, but we
        haven't yet gotten GCC developers to acknowledge that, which doesn't
        inspire confidence in their willingness to keep the feature working as
        optimizations are added or changed going forward.
      - While there *is* a distro which relies on this flag for their distro
        livepatch module builds, there's not a publicly documented way to
        create safe livepatch modules with it.  Its use seems to be based on
        tribal knowledge.  It serves no benefit to those who don't know how to
        use it.
        (In fact, I believe the current livepatch documentation and samples
        are misleading and dangerous, and should be corrected.  Or at least
        amended with a disclaimer.  But I don't feel qualified to make such
      Also, we have an idea for using objtool to detect function changes,
      which could potentially obsolete the need for this flag anyway.
      At this point the flag has no benefits for upstream which would
      counteract the above drawbacks.  Revert it until it becomes more ready.
      This reverts commit 43bd3a95.
      Fixes: 43bd3a95
       ("kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled")
      Reported-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Link: https://lore.kernel.org/r/696262e997359666afa053fe7d1a9fb2bb373964.1595010490.git.jpoimboe@redhat.com
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
  10. 12 Sep, 2020 1 commit
  11. 09 Sep, 2020 1 commit
  12. 05 Sep, 2020 1 commit
  13. 03 Sep, 2020 1 commit
  14. 27 Aug, 2020 1 commit
  15. 26 Aug, 2020 1 commit
  16. 21 Aug, 2020 1 commit
  17. 19 Aug, 2020 1 commit
  18. 11 Aug, 2020 1 commit
  19. 02 Aug, 2020 1 commit
  20. 26 Jul, 2020 1 commit
  21. 23 Jul, 2020 1 commit
  22. 19 Jul, 2020 1 commit
  23. 12 Jul, 2020 1 commit
  24. 11 Jul, 2020 1 commit
  25. 05 Jul, 2020 1 commit
  26. 01 Jul, 2020 1 commit
  27. 28 Jun, 2020 1 commit
  28. 21 Jun, 2020 2 commits
  29. 15 Jun, 2020 1 commit
    • Arvind Sankar's avatar
      Makefile: Improve compressed debug info support detection · 7b169944
      Arvind Sankar authored
       ("Makefile: support compressed debug info")
      added support for compressed debug sections.
      Support is detected by checking
      - does the compiler support -gz=zlib
      - does the assembler support --compressed-debug-sections=zlib
      - does the linker support --compressed-debug-sections=zlib
      However, the gcc driver's support for this option is somewhat
      convoluted. The driver's builtin specs are set based on the version of
      binutils that it was configured with. It reports an error if the
      configure-time linker/assembler (i.e., not necessarily the actual
      assembler that will be run) do not support the option, but only if the
      assembler (or linker) is actually invoked when -gz=zlib is passed.
      The cc-option check in scripts/Kconfig.include does not invoke the
      assembler, so the gcc driver reports success even if it does not support
      the option being passed to the assembler.
      Because the as-option check passes the option directly to the assembler
      via -Wa,--compressed-debug-sections=zlib, the gcc driver does not see
      this option and will never report an error.
      Combined with an installed version of binutils that is more recent than
      the one the compiler was built with, it is possible for all three tests
      to succeed, yet an actual compilation with -gz=zlib to fail.
      Moreover, it is unnecessary to explicitly pass
      --compressed-debug-sections=zlib to the assembler via -Wa, since the
      driver will do that automatically when it supports -gz=zlib.
      Convert the as-option to just -gz=zlib, simplifying it as well as
      performing a better test of the gcc driver's capabilities.
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: default avatarArvind Sankar <nivedita@alum.mit.edu>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
  30. 14 Jun, 2020 1 commit
  31. 11 Jun, 2020 1 commit
  32. 06 Jun, 2020 4 commits
    • Denis Efremov's avatar
      kbuild: add variables for compression tools · 8dfb61dc
      Denis Efremov authored
      Allow user to use alternative implementations of compression tools,
      such as pigz, pbzip2, pxz. For example, multi-threaded tools to
      speed up the build:
      $ make GZIP=pigz BZIP2=pbzip2
      Variables _GZIP, _BZIP2, _LZOP are used internally because original env
      vars are reserved by the tools. The use of GZIP in gzip tool is obsolete
      since 2015. However, alternative implementations (e.g., pigz) still rely
      on it. BZIP2, BZIP, LZOP vars are not obsolescent.
      The credit goes to @grsecurity.
      As a sidenote, for multi-threaded lzma, xz compression one can use:
      $ export XZ_OPT="--threads=0"
      Signed-off-by: default avatarDenis Efremov <efremov@linux.com>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
    • Jonas Zeiger's avatar
      Makefile: install modules.builtin even if CONFIG_MODULES=n · e0b250b5
      Jonas Zeiger authored
      Many applications check for available kernel features via:
        - /proc/modules (loaded modules, present if CONFIG_MODULES=y)
        - $(MODLIB)/modules.builtin (builtin modules)
      They fail to detect features if the kernel was built with CONFIG_MODULES=n
      and modules.builtin isn't installed.
      Therefore, add the target "_builtin_inst_" and make "install" and
      "modules_install" depend on it.
      Tests results:
        - make install: kernel image is copied as before, modules.builtin copied
        - make modules_install: (CONFIG_MODULES=n) nothing is copied, exit 1
      Signed-off-by: default avatarJonas Zeiger <jonas.zeiger@talpidae.net>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
    • Masahiro Yamada's avatar
      modpost: show warning if any of symbol dump files is missing · 48a0f727
      Masahiro Yamada authored
      If modpost fails to load a symbol dump file, it cannot check unresolved
      symbols, hence module dependency will not be added. Nor CRCs can be added.
      Currently, external module builds check only $(objtree)/Module.symvers,
      but it should check files specified by KBUILD_EXTRA_SYMBOLS as well.
      Move the warning message from the top Makefile to scripts/Makefile.modpost
      and print the warning if any dump file is missing.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
    • Masahiro Yamada's avatar
      modpost: generate vmlinux.symvers and reuse it for the second modpost · 269a535c
      Masahiro Yamada authored
      The full build runs modpost twice, first for vmlinux.o and second for
      The first pass dumps all the vmlinux symbols into Module.symvers, but
      the second pass parses vmlinux again instead of reusing the dump file,
      presumably because it needs to avoid accumulating stale symbols.
      Loading symbol info from a dump file is faster than parsing an ELF object.
      Besides, modpost deals with various issues to parse vmlinux in the second
      A solution is to make the first pass dumps symbols into a separate file,
      vmlinux.symvers. The second pass reads it, and parses module .o files.
      The merged symbol information is dumped into Module.symvers in the same
      way as before.
      This makes further modpost cleanups possible.
      Also, it fixes the problem of 'make vmlinux', which previously overwrote
      Module.symvers, throwing away module symbols.
      I slightly touched scripts/link-vmlinux.sh so that vmlinux is re-linked
      when you cross this commit. Otherwise, vmlinux.symvers would not be
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
  33. 03 Jun, 2020 2 commits
  34. 01 Jun, 2020 1 commit