This patch replaces backquote to dollar parenthesis syntax for better
readability.
Signed-off-by: NBhaskar Chowdhury <unixbhaskar@gmail.com>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Acked-by: NNico Schottelius <nico-linuxsetlocalversion@schottelius.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Since commit 394053f4 ("kbuild: make single targets work more
correctly"), building single targets is really slow.

Speed it up by not descending into unrelated directories.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

KBUILD_SINGLE_TARGETS does not need to contain all the targets.
Change it to keep track the targets only from the current directory
and its subdirectories.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Since commit 040fcc81 ("kbuild: improved modversioning support for
external modules"), the external module build reads Module.symvers in
the directory of the module itself, then dumps symbols back into it.
It accumulates stale symbols in the file when you build an external
module incrementally.

The idea behind it was, as the commit log explained, you can copy
Modules.symvers from one module to another when you need to pass symbol
information between two modules. However, the manual copy of the file
sounds questionable to me, and containing stale symbols is a downside.

Some time later, commit 0d96fb20 ("kbuild: Add new Kbuild variable
KBUILD_EXTRA_SYMBOLS") introduced a saner approach.

So, this commit removes the former one. Going forward, the external
module build dumps symbols into Module.symvers to be carried via
KBUILD_EXTRA_SYMBOLS, but never reads it automatically.

With the -I option removed, there is no one to set the external_module
flag unless KBUILD_EXTRA_SYMBOLS is passed. Now the -i option does it
instead.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

When building external modules, $(objtree)/Module.symvers is scanned
for symbol information of vmlinux and in-tree modules.

Additionally, vmlinux is parsed if it exists in $(objtree)/.
This is totally redundant since all the necessary information is
contained in $(objtree)/Module.symvers.

Do not parse vmlinux at all for external module builds. This makes
sense because vmlinux is deleted by 'make clean'.

'make clean' leaves all the build artifacts for building external
modules. vmlinux is unneeded for that.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

The comment line "When building external modules ..." explains
the same thing as "Include the module's Makefile ..." a few lines
below.

The comment "they may be used when building the .mod.c file" is no
longer true; .mod.c file is compiled in scripts/Makefile.modfinal
since commit 9b9a3f20 ("kbuild: split final module linking out
into Makefile.modfinal"). I still keep the code in case $(obj) or
$(src) is used in the external module Makefile.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

util.c exists both in scripts/kconfig/ and scripts/kconfig/lxdialog.

Prior to commit 54b8ae66 ("kbuild: change *FLAGS_<basetarget>.o
to take the path relative to $(obj)"), Kbuild could not pass different
flags to source files with the same basename. Now that this issue
was solved, you can split util.c out of parser.y and compile them
independently of each other.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

This tool is only used by drivers/video/logo/Makefile. No reason to
keep it in scripts/.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

gcc's -freorder-blocks-and-partition option makes it group frequently
and infrequently used code in .text.hot and .text.unlikely sections
respectively.  At least when building modules on s390, this option is
used by default.

gdb assumes that all code is located in .text section, and that .text
section is located at module load address.  With such modules this is no
longer the case: there is code in .text.hot and .text.unlikely, and
either of them might precede .text.

Fix by explicitly telling gdb the addresses of code sections.

It might be tempting to do this for all sections, not only the ones in
the white list.  Unfortunately, gdb appears to have an issue, when
telling it about e.g. loadable .note.gnu.build-id section causes it to
think that non-loadable .note.Linux section is loaded at address 0,
which in turn causes NULL pointers to be resolved to bogus symbols.  So
keep using the white list approach for the time being.

Link: http://lkml.kernel.org/r/20191028152734.13065-1-iii@linux.ibm.comSigned-off-by: NIlya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: NJan Kiszka <jan.kiszka@siemens.com>
Cc: Kieran Bingham <kbingham@kernel.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The nsdeps script passes a list of the module source files to
generate_deps_for_ns() as a space delimited string named $mod_source_files,
which then passes it to spatch. But since $mod_source_files is not encased
in quotes, each source file in that string is treated as a separate shell
function argument (as $2, $3, $4, etc.).  However, the spatch invocation
only refers to $2, so only the first file out of $mod_source_files is
processed by spatch.

This causes problems (namely, the MODULE_IMPORT_NS() statement doesn't
get inserted) when a module is composed of many source files and the
"main" module file containing the MODULE_LICENSE() statement is not the
first file listed in $mod_source_files. Fix this by encasing
$mod_source_files in quotes so that the entirety of the string is
treated as a single argument and can be referred to as $2.

In addition, put quotes in the variable assignment of mod_source_files
to prevent any shell interpretation and field splitting.
Reviewed-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NMatthias Maennich <maennich@google.com>
Signed-off-by: NJessica Yu <jeyu@kernel.org>

When doing an out of tree build with O=, the nsdeps script constructs
the absolute pathname of the module source file so that it can insert
MODULE_IMPORT_NS statements in the right place. However, ${srctree}
contains an unescaped path to the source tree, which, when used in a sed
substitution, makes sed complain:

++ sed 's/[^ ]* *//home/jeyu/jeyu-linux\/&/g'
sed: -e expression #1, char 12: unknown option to `s'

The sed substitution command 's' ends prematurely with the forward
slashes in the pathname, and sed errors out when it encounters the 'h',
which is an invalid sed substitution option. To avoid escaping forward
slashes ${srctree}, we can use '|' as an alternative delimiter for
sed instead to avoid this error.
Reviewed-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NMatthias Maennich <maennich@google.com>
Tested-by: NMatthias Maennich <maennich@google.com>
Signed-off-by: NJessica Yu <jeyu@kernel.org>

Currently lx-symbols assumes that module text is always located at
module->core_layout->base, but s390 uses the following layout:

  +------+  <- module->core_layout->base
  | GOT  |
  +------+  <- module->core_layout->base + module->arch->plt_offset
  | PLT  |
  +------+  <- module->core_layout->base + module->arch->plt_offset +
  | TEXT |     module->arch->plt_size
  +------+

Therefore, when trying to debug modules on s390, all the symbol
addresses are skewed by plt_offset + plt_size.

Fix by adding plt_offset + plt_size to module_addr in
load_module_symbols().

Link: http://lkml.kernel.org/r/20191017085917.81791-1-iii@linux.ibm.comSigned-off-by: NIlya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: NJan Kiszka <jan.kiszka@siemens.com>
Cc: Kieran Bingham <kbingham@kernel.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When CONFIG_PRINTK_CALLER is set, struct printk_log contains an
additional member caller_id.  This affects the offset of the log text.
Account for this by using the type information from gdb to determine all
the offsets instead of using hardcoded values.

This fixes following error:

  (gdb) lx-dmesg
  Python Exception <class 'ValueError'> embedded null character:
  Error occurred in Python command: embedded null character

The read_u* utility functions now take an offset argument to make them
easier to use.

Link: http://lkml.kernel.org/r/20191011142500.2339-1-joel.colledge@linbit.comSigned-off-by: NJoel Colledge <joel.colledge@linbit.com>
Reviewed-by: NJan Kiszka <jan.kiszka@siemens.com>
Cc: Kieran Bingham <kbingham@kernel.org>
Cc: Leonard Crestez <leonard.crestez@nxp.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The introduction of Symbol Namespaces changed the naming schema of the
__ksymtab entries from __kysmtab__symbol to __ksymtab_NAMESPACE.symbol.

That caused some breakages in tools that depend on the name layout in
either the binaries(vmlinux,*.ko) or in System.map. E.g. kmod's depmod
would not be able to read System.map without a patch to support symbol
namespaces. A warning reported by depmod for namespaced symbols would
look like

  depmod: WARNING: [...]/uas.ko needs unknown symbol usb_stor_adjust_quirks

In order to address this issue, revert to the original naming scheme and
rather read the __kstrtabns_<symbol> entries and their corresponding
values from __ksymtab_strings to update the namespace values for
symbols. After having read all symbols and handled them in
handle_modversions(), the symbols are created. In a second pass, read
the __kstrtabns_ entries and update the namespaces accordingly.

Fixes: 8651ec01 ("module: add support for symbol namespaces.")
Reported-by: NStefan Wahren <stefan.wahren@i2se.com>
Suggested-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NWill Deacon <will@kernel.org>
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NMatthias Maennich <maennich@google.com>
Signed-off-by: NJessica Yu <jeyu@kernel.org>

Setting the symbol namespace of a symbol within sym_add_exported feels
displaced and lead to issues in the current implementation of symbol
namespaces. This patch makes updating the namespace an explicit call to
decouple it from adding a symbol to the export list.
Acked-by: NWill Deacon <will@kernel.org>
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NMatthias Maennich <maennich@google.com>
Signed-off-by: NJessica Yu <jeyu@kernel.org>

Let the function 'sym_update_namespace' take care of updating the
namespace for a symbol. While this currently only replaces one single
location where namespaces are updated, in a following patch, this
function will get more call sites.

The function signature is intentionally close to sym_update_crc and
taking the name by char* seems like unnecessary work as the symbol has
to be looked up again. In a later patch of this series, this concern
will be addressed.

This function ensures that symbol::namespace is either NULL or has a
valid non-empty value. Previously, the empty string was considered 'no
namespace' as well and this lead to confusion.
Acked-by: NWill Deacon <will@kernel.org>
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NMatthias Maennich <maennich@google.com>
Signed-off-by: NJessica Yu <jeyu@kernel.org>

While it is useful for new drivers to use devm_platform_ioremap_resource,
this script is currently used to spam maintainers, often updating very
old drivers.  The net benefit is the removal of 2 lines of code in the
driver but the review load for the maintainers is huge.  As of now, more
that 560 patches have been sent, some of them obviously broken, as in:

 https://lore.kernel.org/lkml/9bbcce19c777583815c92ce3c2ff2586@www.loen.fr/

Remove the script to reduce the spam.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix bashism reported by checkbashisms by using only one '=':

possible bashism in scripts/setlocalversion line 96 (should be 'b = a'):
	if [ "`hg log -r . --template '{latesttagdistance}'`" == "1" ]; then

Fixes: 38b3439d ("setlocalversion: update mercurial tag parsing")
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Cc: Mike Crowe <mcrowe@zipitwireless.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

The removal of the longjmp code in recordmcount.c mistakenly made the return
of make_nop() being negative an exit of nop_mcount(). It should not exit the
routine, but instead just not process that part of the code. By exiting with
an error code, it would cause the update of recordmcount to fail some files
which would fail the build if ftrace function tracing was enabled.

Link: http://lkml.kernel.org/r/20191009110538.5909fec6@gandalf.local.homeReported-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Tested-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Fixes: 3f1df120 ("recordmcount: Rewrite error/success handling")
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>

scripts/nsdeps automatically generates a patch to add MODULE_IMPORT_NS
tags, and what is nicer, it sorts the lines alphabetically with the
'sort' command. However, the output from the 'sort' command depends on
locale.

For example, I got this:

$ { echo usbstorage; echo usb_storage; } | LANG=en_US.UTF-8 sort
usbstorage
usb_storage
$ { echo usbstorage; echo usb_storage; } | LANG=C sort
usb_storage
usbstorage

So, this means people might potentially send different patches.

This kind of issue was reported in the past, for example,
commit f55f2328 ("kbuild: make sorting initramfs contents
independent of locale").

Adding 'LANG=C' is a conventional way of fixing when a deterministic
result is desirable.

I added 'LANG=C' very close to the 'sort' command since changing
locale affects the language of error messages etc. We should respect
users' choice as much as possible.
Reviewed-by: NMatthias Maennich <maennich@google.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NJessica Yu <jeyu@kernel.org>

This script does not use bash-extension. I am guessing this hashbang
was copied from scripts/coccicheck, which really uses bash-extension.

/bin/sh is enough for this script.
Reviewed-by: NMatthias Maennich <maennich@google.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NJessica Yu <jeyu@kernel.org>

Currently, external module builds produce tons of false-positives:

  WARNING: module <mod> uses symbol <sym> from namespace <ns>, but does not import it.

Here, the <ns> part shows a random string.

When you build external modules, the symbol info of vmlinux and
in-kernel modules are read from $(objtree)/Module.symvers, but
read_dump() is buggy in multiple ways:

[1] When the modpost is run for vmlinux and in-kernel modules,
sym_extract_namespace() allocates memory for the namespace. On the
other hand, read_dump() does not, then sym->namespace will point to
somewhere in the line buffer of get_next_line(). The data in the
buffer will be replaced soon, and sym->namespace will end up with
pointing to unrelated data. As a result, check_exports() will show
random strings in the warning messages.

[2] When there is no namespace, sym_extract_namespace() returns NULL.
On the other hand, read_dump() sets namespace to an empty string "".
(but, it will be later replaced with unrelated data due to bug [1].)
The check_exports() shows a warning unless exp->namespace is NULL,
so every symbol read from read_dump() emits the warning, which is
mostly false positive.

To address [1], sym_add_exported() calls strdup() for s->namespace.
The namespace from sym_extract_namespace() must be freed to avoid
memory leak.

For [2], I changed the if-conditional in check_exports().

This commit also fixes sym_add_exported() to set s->namespace correctly
when the symbol is preloaded.
Reviewed-by: NMatthias Maennich <maennich@google.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NJessica Yu <jeyu@kernel.org>

Currently, EXPORT_SYMBOL_NS(_GPL) constructs the kernel symbol as
follows:

  __ksymtab_SYMBOL.NAMESPACE

The sym_extract_namespace() in modpost allocates memory for the part
SYMBOL.NAMESPACE when '.' is contained. One problem is that the pointer
returned by strdup() is lost because the symbol name will be copied to
malloc'ed memory by alloc_symbol(). No one will keep track of the
pointer of strdup'ed memory.

sym->namespace still points to the NAMESPACE part. So, you can free it
with complicated code like this:

   free(sym->namespace - strlen(sym->name) - 1);

It complicates memory free.

To fix it elegantly, I swapped the order of the symbol and the
namespace as follows:

  __ksymtab_NAMESPACE.SYMBOL

then, simplified sym_extract_namespace() so that it allocates memory
only for the NAMESPACE part.

I prefer this order because it is intuitive and also matches to major
languages. For example, NAMESPACE::NAME in C++, MODULE.NAME in Python.
Reviewed-by: NMatthias Maennich <maennich@google.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NJessica Yu <jeyu@kernel.org>

Now all scripts in scripts/coccinelle to be automatically called
by coccicheck. However new adding add_namespace.cocci does not
support report mode, which make coccicheck failed.
This add "virtual report" to  make the coccicheck go ahead smoothly.

Fixes: eb8305ae ("scripts: Coccinelle script for namespace dependencies.")
Acked-by: NJulia Lawall <julia.lawall@lip6.fr>
Acked-by: NMatthias Maennich <maennich@google.com>
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NJessica Yu <jeyu@kernel.org>

Geert Uytterhoeven reports a strange side-effect of commit 858805b3
("kbuild: add $(BASH) to run scripts with bash-extension"), which
inserts the contents of a localversion file in the build directory twice.

[Steps to Reproduce]
  $ echo bar > localversion
  $ mkdir build
  $ cd build/
  $ echo foo > localversion
  $ make -s -f ../Makefile defconfig include/config/kernel.release
  $ cat include/config/kernel.release
  5.4.0-rc1foofoobar

This comes down to the behavior change of local variables.

The 'man sh' on my Ubuntu machine, where sh is an alias to dash,
explains as follows:
  When a variable is made local, it inherits the initial value and
  exported and readonly flags from the variable with the same name
  in the surrounding scope, if there is one. Otherwise, the variable
  is initially unset.

[Test Code]

  foo ()
  {
          local res
          echo "res: $res"
  }

  res=1
  foo

[Result]

  $ sh test.sh
  res: 1
  $ bash test.sh
  res:

So, scripts/setlocalversion correctly works only for bash in spite of
its hashbang being #!/bin/sh. Nobody had noticed it before because
CONFIG_SHELL was previously set to bash almost all the time.

Now that CONFIG_SHELL is set to sh, we must write portable and correct
code. I gave the Fixes tag to the commit that uncovered the issue.

Clear the variable 'res' in collect_files() to make it work for sh
(and it also works on distributions where sh is an alias to bash).

Fixes: 858805b3 ("kbuild: add $(BASH) to run scripts with bash-extension")
Reported-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>

The namespace.pl script does not work properly if objtree is not set to
an absolute path. The do_nm function is run from within the find
function, which changes directories.

Because of this, appending objtree, $File::Find::dir, and $source, will
return a path which is not valid from the current directory.

This used to work when objtree was set to an absolute path when using
"make namespacecheck". It appears to have not worked when calling
./scripts/namespace.pl directly.

This behavior was changed in 7e1c0477 ("kbuild: Use relative path
for $(objtree)", 2014-05-14)

Rather than fixing the Makefile to set objtree to an absolute path, just
fix namespace.pl to work when srctree and objtree are relative. Also fix
the script to use an absolute path for these by default.

Use the File::Spec module for this purpose. It's been part of perl
5 since 5.005.

The curdir() function is used to get the current directory when the
objtree and srctree aren't set in the environment.

rel2abs() is used to convert possibly relative objtree and srctree
environment variables to absolute paths.

Finally, the catfile() function is used instead of string appending
paths together, since this is more robust when joining paths together.
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Tested-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Johannes Berg reports lots of modpost warnings on ARCH=um builds:

WARNING: "rename" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "lseek" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "ftruncate64" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "getuid" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "lseek64" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "unlink" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "pwrite64" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "close" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "opendir" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "pread64" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "syscall" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "readdir" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "readdir64" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "futimes" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "__lxstat" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "write" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "closedir" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "__xstat" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "fsync" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "__lxstat64" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "__fxstat64" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "telldir" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "printf" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "readlink" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "__sprintf_chk" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "link" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "rmdir" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "fdatasync" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "truncate" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "statfs" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "__errno_location" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "__xmknod" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "open64" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "truncate64" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "open" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "read" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "chown" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "chmod" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "utime" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "fchmod" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "seekdir" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "ioctl" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "dup2" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "statfs64" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "utimes" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "mkdir" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "fchown" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "__guard" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "symlink" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "access" [vmlinux] is a static EXPORT_SYMBOL
WARNING: "__stack_smash_handler" [vmlinux] is a static EXPORT_SYMBOL

When you run "make", the modpost is run twice; before linking vmlinux,
and before building modules. All the warnings above are from the second
modpost.

The offending symbols are defined not in vmlinux, but in the C library.
The first modpost is run against the relocatable vmlinux.o, and those
warnings are nicely suppressed because the SH_UNDEF entries from the
symbol table clear the ->is_static flag.

The second modpost is run against the executable vmlinux (+ modules),
where those symbols have been resolved, but the definitions do not
exist.

This commit fixes it in a straightforward way; suppress the static
EXPORT_SYMBOL warnings from "vmlinux".

Without this commit, we see valid warnings twice anyway. For example,
ARCH=arm64 defconfig shows the following warning twice:

WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL

So, it is reasonable to suppress the second one.

Fixes: 15bfc234 ("modpost: check for static EXPORT_SYMBOL* functions")
Reported-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: NJohannes Berg <johannes@sipsolutions.net>
Tested-by: NDenis Efremov <efremov@linux.com>

Commit 40df759e ("kbuild: Fix build with binutils <= 2.19")
introduced ar-option and KBUILD_ARFLAGS to deal with old binutils.

According to Documentation/process/changes.rst, the current minimal
supported version of binutils is 2.21 so you can assume the 'D' option
is always supported. Not only GNU ar but also llvm-ar supports it.

With the 'D' option hard-coded, there is no more user of ar-option
or KBUILD_ARFLAGS.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
Tested-by: NNick Desaulniers <ndesaulniers@google.com>

IS_ERR(), IS_ERR_OR_NULL(), IS_ERR_VALUE() and WARN*() already contain
unlikely() optimization internally.  Thus, there is no point in calling
these functions and defines under likely()/unlikely().

This check is based on the coccinelle rule developed by Enrico Weigelt
https://lore.kernel.org/lkml/1559767582-11081-1-git-send-email-info@metux.net/

Link: http://lkml.kernel.org/r/20190829165025.15750-1-efremov@linux.comSigned-off-by: NDenis Efremov <efremov@linux.com>
Cc: Joe Perches <joe@perches.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Anton Altaparmakov <anton@tuxera.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Boris Pismenny <borisp@mellanox.com>
Cc: Darrick J. Wong <darrick.wong@oracle.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Denis Efremov <efremov@linux.com>
Cc: Dennis Dalessandro <dennis.dalessandro@intel.com>
Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Mike Marciniszyn <mike.marciniszyn@intel.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Saeed Mahameed <saeedm@mellanox.com>
Cc: Sean Paul <sean@poorly.run>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Some systems (like Chrome OS) may use "split debug" for kernel modules.
That means that the debug symbols are in a different file than the main
elf file.  Let's handle that by also searching for debug symbols that end
in ".ko.debug".

This is a packaging topic.  You can take a normal elf file and split the
debug out of it using objcopy.  Try "man objcopy" and then take a look at
the "--only-keep-debug" option.  It'll give you a whole recipe for doing
splitdebug.  The suffix used for the debug symbols is arbitrary.  If
people have other another suffix besides ".ko.debug" then we could
presumably support that too...

For portage (which is the packaging system used by Chrome OS) split debug
is supported by default (and the suffix is .ko.debug).  ...and so in
Chrome OS we always get the installed elf files stripped and then the
symbols stashed away.

At the moment we don't actually use the normal portage magic to do this
for the kernel though since it affects our ability to get good stack dumps
in the kernel.  We instead pass a script as "strip" [1].

[1] https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/master/eclass/cros-kernel/strip_splitdebug

Link: http://lkml.kernel.org/r/20190730234052.148744-1-dianders@chromium.orgSigned-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Reviewed-by: NJan Kiszka <jan.kiszka@siemens.com>
Cc: Kieran Bingham <kbingham@kernel.org>
Cc: Jason Wessel <jason.wessel@windriver.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

git output parsing depends on the language being en_US english.

Make the backtick execution of all `git <foo>` commands set the
LANGUAGE of the process to en_US.utf8 before executing the actual
command using `export LANGUAGE=en_US.utf8; git <foo>`.

Because the command is executed in a child process, the parent
LANGUAGE is unchanged.

Link: http://lkml.kernel.org/r/bb9f29988f3258281956680ff39c3e19e37dc0b8.camel@perches.comSigned-off-by: NJoe Perches <joe@perches.com>
Reported-by: NSean Christopherson <sean.j.christopherson@intel.com>
Reviewed-by: NSean Christopherson <sean.j.christopherson@intel.com>
Tested-by: NSean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Git dropped the period from its "ambiguous SHA1" error message in commit
0c99171ad2 ("get_short_sha1: mark ambiguity error for translation"), circa
2016.  Drop the period from checkpatch's associated query so as to match
both the old and new error messages.

Link: http://lkml.kernel.org/r/20190830163103.15914-1-sean.j.christopherson@intel.comSigned-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
Acked-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

checkpatch allows consecutive open braces, so it should also allow
consecutive close braces.

Link: http://lkml.kernel.org/r/bfdb49ae2c3fa7b52fa168769e38b48f959880e2.camel@perches.comSigned-off-by: NJoe Perches <joe@perches.com>
Acked-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add another test for __attribute__((section("foo"))) uses that should be
__section(foo)

Link: http://lkml.kernel.org/r/2f374c3c27054b7f978115270d587c624d9962fc.camel@perches.comSuggested-by: NNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: NJoe Perches <joe@perches.com>
Tested-by: NNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The arguments of sizeof are not evaluated so arguments are safe to re-use
in that context.  Excluding sizeof subexpressions means macros like
ARRAY_SIZE can pass checkpatch.

Link: http://lkml.kernel.org/r/20190806070833.24423-1-brendan.jackman@bluwireless.co.ukSigned-off-by: NBrendan Jackman <brendan.jackman@bluwireless.co.uk>
Acked-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

It can happen that a commit message refers to an invalid commit id,
because the referenced hash changed following a rebase, or simply by
mistake.  Add a check in checkpatch.pl which checks that an hash
referenced by a Fixes tag, or just cited in the commit message, is a valid
commit id.

    $ scripts/checkpatch.pl <<'EOF'
    Subject: [PATCH] test commit

    Sample test commit to test checkpatch.pl
    Commit 1da177e4 ("Linux-2.6.12-rc2") really exists,
    commit 0bba044c4ce7 ("tree") is valid but not a commit,
    while commit b4cc0b1c0cca ("unknown") is invalid.

    Fixes: f0cacc14cade ("unknown")
    Fixes: 1da177e4 ("Linux-2.6.12-rc2")
    EOF
    WARNING: Unknown commit id '0bba044c4ce7', maybe rebased or not pulled?
    #8:
    commit 0bba044c4ce7 ("tree") is valid but not a commit,

    WARNING: Unknown commit id 'b4cc0b1c0cca', maybe rebased or not pulled?
    #9:
    while commit b4cc0b1c0cca ("unknown") is invalid.

    WARNING: Unknown commit id 'f0cacc14cade', maybe rebased or not pulled?
    #11:
    Fixes: f0cacc14cade ("unknown")

    total: 0 errors, 3 warnings, 4 lines checked

Link: http://lkml.kernel.org/r/20190711001640.13398-1-mcroce@redhat.comSigned-off-by: NMatteo Croce <mcroce@redhat.com>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Use perl's m@<match>@ match and not /<match>/ comparisons to avoid
an error using c90's // comment style.

Miscellanea:

o Use normal tab indentation and alignment

Link: http://lkml.kernel.org/r/5e4a8fa7901148fbcd77ab391e6dd0e6bf95777f.camel@perches.com

Link: http://lkml.kernel.org/r/f08eb62458407a145cfedf959d1091af151cd665.1563575364.git.joe@perches.comSigned-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add more types of lines that appear to be stack dumps that also include
hex lines that might otherwise be interpreted as commit IDs.

Link: http://lkml.kernel.org/r/ff00208289224f0ca4eaf4ff7c9c6e087dad0a63.camel@perches.com

Link: http://lkml.kernel.org/r/f7dc9727795db3802809a24162abe0b67e14123b.1563575364.git.joe@perches.comSigned-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

I used the C comment style (/* ... */) for the flex and bison files
as in Kconfig (scripts/kconfig/{lexer.l,parser.y})
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Use the __section() shorthand. This avoids escaping double-quotes,
and improves the readability.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>