Skip to content

GitLab

Switch branch/tag
  1. 18 Sep, 2021 3 commits
  3. 16 Sep, 2021 1 commit
  5. 15 Sep, 2021 1 commit
  7. 12 Sep, 2021 1 commit
  9. 08 Sep, 2021 1 commit
  11. 03 Sep, 2021 1 commit
  13. 29 Aug, 2021 1 commit
  15. 22 Aug, 2021 1 commit
  17. 15 Aug, 2021 1 commit
  19. 08 Aug, 2021 1 commit
  21. 05 Aug, 2021 1 commit
  23. 04 Aug, 2021 1 commit
  25. 02 Aug, 2021 1 commit
  27. 25 Jul, 2021 1 commit
  29. 18 Jul, 2021 2 commits
  31. 16 Jul, 2021 1 commit
    • Linus Torvalds's avatar
      Revert "Makefile: Enable -Wimplicit-fallthrough for Clang" · d936eb23
      Linus Torvalds authored 
      This reverts commit b7eb335e.

It turns out that the problem with the clang -Wimplicit-fallthrough
warning is not about the kernel source code, but about clang itself, and
that the warning is unusable until clang fixes its broken ways.

In particular, when you enable this warning for clang, you not only get
warnings about implicit fallthroughs.  You also get this:

   warning: fallthrough annotation in unreachable code [-Wimplicit-fallthrough]

which is completely broken becasue it

 (a) doesn't even tell you where the problem is (seriously: no line
     numbers, no filename, no nothing).

 (b) is fundamentally broken anyway, because there are perfectly valid
     reasons to have a fallthrough statement even if it turns out that
     it can perhaps not be reached.

In the kernel, an example of that second case is code in the scheduler:

                switch (state) {
                case cpuset:
                        if (IS_ENABLED(CONFIG_CPUSETS)) {
                                cpuset_cpus_allowed_fallback(p);
                                state = possible;
                                break;
                        }
                        fallthrough;
                case possible:

where if CONFIG_CPUSETS is enabled you actually never hit the
fallthrough case at all.  But that in no way makes the fallthrough
wrong.

So the warning is completely broken, and enabling it for clang is a very
bad idea.

In the meantime, we can keep the gcc option enabled, and make the gcc
build use

    -Wimplicit-fallthrough=5

which means that we will at least continue to require a proper
fallthrough statement, and that gcc won't silently accept the magic
comment versions. Because gcc does this all correctly, and while the odd
"=5" part is kind of obscure, it's documented in [1]:

  "-Wimplicit-fallthrough=5 doesn’t recognize any comments as
   fallthrough comments, only attributes disable the warning"

so if clang ever fixes its bad behavior we can try enabling it there again.

Link: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

 [1]
Cc: Kees Cook <keescook@chromium.org>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d936eb23
  33. 14 Jul, 2021 1 commit
    • Gustavo A. R. Silva's avatar
      Makefile: Enable -Wimplicit-fallthrough for Clang · b7eb335e
      Gustavo A. R. Silva authored 
      
With the recent fixes for fallthrough warnings, it is now possible to
enable -Wimplicit-fallthrough for Clang.

It's important to mention that since we have adopted the use of the
pseudo-keyword macro fallthrough; we also want to avoid having more
/* fall through */ comments being introduced. Notice that contrary
to GCC, Clang doesn't recognize any comments as implicit fall-through
markings when the -Wimplicit-fallthrough option is enabled. So, in
order to avoid having more comments being introduced, we have to use
the option -Wimplicit-fallthrough=5 for GCC, which similar to Clang,
will cause a warning in case a code comment is intended to be used
as a fall-through marking.
Co-developed-by: default avatarKees Cook <keescook@chromium.org>
Signed-off-by: default avatarKees Cook <keescook@chromium.org>
Signed-off-by: default avatarGustavo A. R. Silva <gustavoars@kernel.org>
      b7eb335e
  35. 11 Jul, 2021 1 commit
  37. 27 Jun, 2021 1 commit
  39. 20 Jun, 2021 1 commit
  41. 17 Jun, 2021 1 commit
    • Masahiro Yamada's avatar
      kbuild: remove trailing slashes from $(KBUILD_EXTMOD) · 74ee585b
      Masahiro Yamada authored 
      M= (or KBUILD_EXTMOD) generally expects a directory path without any
trailing slashes, like M=a/b/c.

If you add a trailing slash, like M=a/b/c/, you will get ugly build
logs (two slashes in a series), but it still works fine as long as it
is consistent between 'make modules' and 'make modules_install'.

The following commands correctly build and install the modules.

  $ make M=a/b/c/ modules
  $ sudo make M=a/b/c/ modules_install

Since commit ccae4cfa ("kbuild: refactor scripts/Makefile.modinst"),
a problem happens if you add a trailing slash only for modules_install.

  $ make M=a/b/c modules
  $ sudo make M=a/b/c/ modules_install

No module is installed in this case, Johannes Berg reported. [1]

Trim any trailing slashes from $(KBUILD_EXTMOD).

I used the 'dirname' command to remove all the trailing slashes in
case someone adds more slashes like M=a/b/c/////. The Make's built-in
function, $(dir ...) cannot take care of such a case.

[1]: https://lore.kernel.org/lkml/10cc8522b27a051e6a9c3e158a4c4b6414fd04a0.camel@sipsolutions.net/

Fixes: ccae4cfa

 ("kbuild: refactor scripts/Makefile.modinst")
Reported-by: default avatarJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      74ee585b
  43. 14 Jun, 2021 1 commit
  45. 13 Jun, 2021 1 commit
  47. 08 Jun, 2021 1 commit
  49. 06 Jun, 2021 1 commit
  51. 30 May, 2021 1 commit
  53. 26 May, 2021 2 commits
  55. 24 May, 2021 4 commits
    • Nick Desaulniers's avatar
      Makefile: LTO: have linker check -Wframe-larger-than · 24845dcb
      Nick Desaulniers authored 
      
-Wframe-larger-than= requires stack frame information, which the
frontend cannot provide. This diagnostic is emitted late during
compilation once stack frame size is available.

When building with LTO, the frontend simply lowers C to LLVM IR and does
not have stack frame information, so it cannot emit this diagnostic.
When the linker drives LTO, it restarts optimizations and lowers LLVM IR
to object code. At that point, it has stack frame information but
doesn't know to check for a specific max stack frame size.

I consider this a bug in LLVM that we need to fix. There are some
details we're working out related to LTO such as which value to use when
there are multiple different values specified per TU, or how to
propagate these to compiler synthesized routines properly, if at all.

Until it's fixed, ensure we don't miss these. At that point we can wrap
this in a compiler version guard or revert this based on the minimum
support version of Clang.

The error message is not generated during link:
  LTO     vmlinux.o
ld.lld: warning: stack size limit exceeded (8224) in foobarbaz

Cc: Sami Tolvanen <samitolvanen@google.com>
Reported-by: default avatarCandle Sun <candlesea@gmail.com>
Suggested-by: default avatarFangrui Song <maskray@google.com>
Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: default avatarKees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210312010942.1546679-1-ndesaulniers@google.com
      24845dcb
    • Masahiro Yamada's avatar
      kbuild: remove libelf checks from top Makefile · 0d989ac2
      Masahiro Yamada authored 
      I do not see a good reason why only the libelf development package must
be so carefully checked.

Kbuild generally does not check host tools or libraries.

For example, x86_64 defconfig fails to build with no libssl development
package installed.

scripts/extract-cert.c:21:10: fatal error: openssl/bio.h: No such file or directory
   21 | #include <openssl/bio.h>
      |          ^~~~~~~~~~~~~~~

To solve the build error, you need to install libssl-dev or openssl-devel
package, depending on your distribution.

'apt-file search', 'dnf provides', etc. is your frined to find a proper
package to install.

This commit removes all the libelf checks from the top Makefile.

If libelf is missing, objtool will fail to build in a similar pattern:

.../linux/tools/objtool/include/objtool/elf.h:10:10: fatal error: gelf.h: No such file or directory
   10 | #include <gelf.h>

You need to install libelf-dev, libelf-devel, or elfutils-libelf-devel
to proceed.

Another remarkable change is, CONFIG_STACK_VALIDATION (without
CONFIG_UNWINDER_ORC) previously continued to build with a warning,
but now it will treat missing libelf as an error.

This is just a one-time installation, so it should not hurt to break
a build and make a user install the package.

BTW, the traditional way to handle such checks is autotool, but according
to [1], I do not expect the kernel build would have similar scripting
like './configure' does.

[1]: https://lore.kernel.org/lkml/CA+55aFzr2HTZVOuzpHYDwmtRJLsVzE-yqg2DHpHi_9ePsYp5ug@mail.gmail.com/

Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
Acked-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      0d989ac2
    • Masahiro Yamada's avatar
      kbuild: hide tools/ build targets from external module builds · 1bb0b18a
      Masahiro Yamada authored 
      
The tools/ directory only exists in the kernel source tree, not in
external modules.

Do not expose the meaningless targets to external modules.
Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      1bb0b18a
    • Feng Tang's avatar
      Makefile: extend 32B aligned debug option to 64B aligned · cf536e18
      Feng Tang authored 
      Commit 09c60546 ("./Makefile: add debug option to enable
function aligned on 32 bytes") was introduced to help debugging
strange kernel performance changes caused by code alignment
change.

Recently we found 2 similar cases [1][2] caused by code-alignment
changes, which can only be identified by forcing 64 bytes aligned
for all functions.

Originally, 32 bytes was used mainly for not wasting too much
text space, but this option is only for debug anyway where text
space is not a big concern. So extend the alignment to 64 bytes
to cover more similar cases.

[1].https://lore.kernel.org/lkml/20210427090013.GG32408@xsang-OptiPlex-9020/
[2].https://lore.kernel.org/lkml/20210420030837.GB31773@xsang-OptiPlex-9020/

Signed-off-by: default avatarFeng Tang <feng.tang@intel.com>
Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      cf536e18
  57. 23 May, 2021 1 commit
  59. 16 May, 2021 1 commit
  61. 09 May, 2021 1 commit
  63. 05 May, 2021 2 commits