Skip to content

K
Kernel

openeuler / Kernel
大约 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 21 12月, 2020 5 次提交
    • M
      modpost: turn section mismatches to error from fatal() · c7299d98
      由 Masahiro Yamada 提交于 
      There is code that reports static EXPORT_SYMBOL a few lines below.
It is not a good idea to bail out here.

I renamed sec_mismatch_fatal to sec_mismatch_warn_only (with logical
inversion) to match to CONFIG_SECTION_MISMATCH_WARN_ONLY.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      c7299d98
    • M
      modpost: change license incompatibility to error() from fatal() · d6d692fa
      由 Masahiro Yamada 提交于 
      Change fatal() to error() to continue running to report more possible
issues.

There is no difference in the fact that modpost will fail anyway.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      d6d692fa
    • M
      modpost: turn missing MODULE_LICENSE() into error · 1d6cd392
      由 Masahiro Yamada 提交于 
      Do not create modules with no license tag.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      1d6cd392
    • M
      modpost: refactor error handling and clarify error/fatal difference · 0fd3fbad
      由 Masahiro Yamada 提交于 
      We have 3 log functions. fatal() is special because it lets modpost bail
out immediately. The difference between warn() and error() is the only
prefix parts ("WARNING:" vs "ERROR:").

In my understanding, the expected handling of error() is to propagate
the return code of the function to the exit code of modpost, as
check_exports() etc. already does. This is a good manner in general
because we should display as many error messages as possible in a
single run of modpost.

What is annoying about fatal() is that it kills modpost at the first
error. People would need to run Kbuild again and again until they fix
all errors.

But, unfortunately, people tend to do:
"This case should not be allowed. Let's replace warn() with fatal()."

One of the reasons is probably it is tedious to manually hoist the error
code to the main() function.

This commit refactors error() so any single call for it automatically
makes modpost return the error code.

I also added comments in modpost.h for warn(), error(), and fatal().

Please use fatal() only when you have a strong reason to do so.
For example:

  - Memory shortage (i.e. malloc() etc. has failed)
  - The ELF file is broken, and there is no point to continue parsing
  - Something really odd has happened

For general coding errors, please use error().
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Tested-by: NQuentin Perret <qperret@google.com>
      0fd3fbad
    • M
      modpost: rename merror() to error() · bc72d723
      由 Masahiro Yamada 提交于 
      The log function names, warn(), merror(), fatal() are inconsistent.

Commit 2a116659 ("kbuild: distinguish between errors and warnings
in modpost") intentionally chose merror() to avoid the conflict with
the library function error(). See man page of error(3).

But, we are already causing the conflict with warn() because it is also
a library function. See man page of warn(3). err() would be a problem
for the same reason.

The common technique to work around name conflicts is to use macros.
For example:

    /* in a header */
    #define error(fmt, ...)  __error(fmt, ##__VA_ARGS__)
    #define warn(fmt, ...)   __warn(fmt, ##__VA_ARGS__)

    /* function definition */
    void __error(const char *fmt, ...)
    {
            <our implementation>
    }

    void __warn(const char *fmt, ...)
    {
            <our implementation>
    }

In this way, we can implement our own warn() and error(), still we can
include <error.h> and <err.h> with no problem.

And, commit 93c95e52 ("modpost: rework and consolidate logging
interface") already did that.

Since the log functions are all macros, we can use error() without
causing "conflicting types" errors.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      bc72d723
  3. 08 12月, 2020 2 次提交
  5. 06 12月, 2020 1 次提交
    • M
      kbuild: avoid split lines in .mod files · 7d32358b
      由 Masahiro Yamada 提交于 
      "xargs echo" is not a safe way to remove line breaks because the input
may exceed the command line limit and xargs may break it up into
multiple invocations of echo. This should never happen because
scripts/gen_autoksyms.sh expects all undefined symbols are placed in
the second line of .mod files.

One possible way is to replace "xargs echo" with
"sed ':x;N;$!bx;s/\n/ /g'" or something, but I rewrote the code by
using awk because it is more readable.

This issue was reported by Sami Tolvanen; in his Clang LTO patch set,
$(multi-used-m) is no longer an ELF object, but a thin archive that
contains LLVM bitcode files. llvm-nm prints out symbols for each
archive member separately, which results a lot of dupications, in some
places, beyond the system-defined limit.

This problem must be fixed irrespective of LTO, and we must ensure
zero possibility of having this issue.

Link: https://lkml.org/lkml/2020/12/1/1658Reported-by: NSami Tolvanen <samitolvanen@google.com>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NSami Tolvanen <samitolvanen@google.com>
      7d32358b
  7. 01 12月, 2020 1 次提交
  9. 25 11月, 2020 1 次提交
    • A
      Makefile.extrawarn: move -Wcast-align to W=3 · 095fbca0
      由 Arnd Bergmann 提交于 
      This warning behaves differently depending on the architecture
and compiler. Using x86 gcc, we get no output at all because
gcc knows the architecture can handle unaligned accesses.

Using x86 clang, or gcc on an architecture that needs to
manually deal with unaligned accesses, the build log is
completely flooded with these warnings, as they are commonly
invoked by inline functions of networking headers, e.g.

include/linux/skbuff.h:1426:26: warning: cast increases required alignment of target type [-Wcast-align]

The compiler is correct to point this out, as we are dealing
with undefined behavior that does cause problems in practice,
but there is also no good way to rewrite the code in commonly
included headers to a safer method.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      095fbca0
  11. 02 11月, 2020 3 次提交
  13. 30 10月, 2020 13 次提交
  15. 29 10月, 2020 4 次提交
  17. 26 10月, 2020 2 次提交
  19. 22 10月, 2020 1 次提交
  21. 20 10月, 2020 3 次提交
  23. 18 10月, 2020 1 次提交
  25. 17 10月, 2020 3 次提交