Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. Dec 24, 2020
    • Sumera Priyadarsini's avatar
      scripts: coccicheck: Correct usage of make coccicheck · d8f6e5c6
      Sumera Priyadarsini authored 
      
The command "make coccicheck C=1 CHECK=scripts/coccicheck" results in the
error:
        ./scripts/coccicheck: line 65: -1: shift count out of range

This happens because every time the C variable is specified,
the shell arguments need to be "shifted" in order to take only
the last argument, which is the C file to test. These shell arguments
mostly comprise flags that have been set in the Makefile. However,
when coccicheck is specified in the make command as a rule, the
number of shell arguments is zero, thus passing the invalid value -1
to the shift command, resulting in an error.

Modify coccicheck to print correct usage of make coccicheck so as to
avoid the error.

Signed-off-by: default avatarSumera Priyadarsini <sylphrenadin@gmail.com>
Signed-off-by: default avatarJulia Lawall <Julia.Lawall@inria.fr>
      d8f6e5c6
  3. Dec 22, 2020
  5. Dec 21, 2020
    • Masahiro Yamada's avatar
      kconfig: fix return value of do_error_if() · 135b4957
      Masahiro Yamada authored 
      
$(error-if,...) is expanded to an empty string. Currently, it relies on
eval_clause() returning xstrdup("") when all attempts for expansion fail,
but the correct implementation is to make do_error_if() return xstrdup("").

Fixes: 1d6272e6 ("kconfig: add 'info', 'warning-if', and 'error-if' built-in functions")
Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      135b4957
    • Marco Elver's avatar
      genksyms: Ignore module scoped _Static_assert() · 9ab55d7f
      Marco Elver authored 
      
The C11 _Static_assert() keyword may be used at module scope, and we
need to teach genksyms about it to not abort with an error. We currently
have a growing number of static_assert() (but also direct usage of
_Static_assert()) users at module scope:

	git grep -E '^_Static_assert\(|^static_assert\(' | grep -v '^tools' | wc -l
	135

More recently, when enabling CONFIG_MODVERSIONS with CONFIG_KCSAN, we
observe a number of warnings:

	WARNING: modpost: EXPORT symbol "<..all kcsan symbols..>" [vmlinux] [...]

When running a preprocessed source through 'genksyms -w' a number of
syntax errors point at usage of static_assert()s. In the case of
kernel/kcsan/encoding.h, new static_assert()s had been introduced which
used expressions that appear to cause genksyms to not even be able to
recover from the syntax error gracefully (as it appears was the case
previously).

Therefore, make genksyms ignore all _Static_assert() and the contained
expression. With the fix, usage of _Static_assert() no longer cause
"syntax error" all over the kernel, and the above modpost warnings for
KCSAN are gone, too.

Signed-off-by: default avatarMarco Elver <elver@google.com>
Acked-by: default avatarNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      9ab55d7f
    • Quentin Perret's avatar
      modpost: turn static exports into error · b9ed847b
      Quentin Perret authored 
      
Using EXPORT_SYMBOL*() on static functions is fundamentally wrong.
Modpost currently reports that as a warning, but clearly this is not a
pattern we should allow, and all in-tree occurences should have been
fixed by now. So, promote the warn() message to error() to make sure
this never happens again.

Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: default avatarMatthias Maennich <maennich@google.com>
Signed-off-by: default avatarQuentin Perret <qperret@google.com>
Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      b9ed847b
    • Masahiro Yamada's avatar
      modpost: turn section mismatches to error from fatal() · c7299d98
      Masahiro Yamada authored 
      
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: default avatarMasahiro Yamada <masahiroy@kernel.org>
      c7299d98
    • Masahiro Yamada's avatar
      modpost: change license incompatibility to error() from fatal() · d6d692fa
      Masahiro Yamada authored 
      
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: default avatarMasahiro Yamada <masahiroy@kernel.org>
      d6d692fa
    • Masahiro Yamada's avatar
      modpost: turn missing MODULE_LICENSE() into error · 1d6cd392
      Masahiro Yamada authored 
      
Do not create modules with no license tag.

Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      1d6cd392
    • Masahiro Yamada's avatar
      modpost: refactor error handling and clarify error/fatal difference · 0fd3fbad
      Masahiro Yamada authored 
      
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: default avatarMasahiro Yamada <masahiroy@kernel.org>
Tested-by: default avatarQuentin Perret <qperret@google.com>
      0fd3fbad
    • Masahiro Yamada's avatar
      modpost: rename merror() to error() · bc72d723
      Masahiro Yamada authored 
      
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: default avatarMasahiro Yamada <masahiroy@kernel.org>
      bc72d723
  7. Dec 16, 2020
  9. Dec 15, 2020
  11. Dec 12, 2020
  13. Dec 08, 2020