- 13 10月, 2019 1 次提交
-
-
由 Steven Rostedt (VMware) 提交于
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>
-
- 08 10月, 2019 4 次提交
-
-
由 Masahiro Yamada 提交于
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>
-
由 Masahiro Yamada 提交于
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>
-
由 Masahiro Yamada 提交于
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>
-
由 Masahiro Yamada 提交于
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>
-
- 07 10月, 2019 1 次提交
-
-
由 YueHaibing 提交于
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>
-
- 05 10月, 2019 2 次提交
-
-
由 Masahiro Yamada 提交于
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>
-
由 Jacob Keller 提交于
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>
-
- 01 10月, 2019 2 次提交
-
-
由 Masahiro Yamada 提交于
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>
-
由 Masahiro Yamada 提交于
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>
-
- 26 9月, 2019 10 次提交
-
-
由 Denis Efremov 提交于
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>
-
由 Douglas Anderson 提交于
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>
-
由 Joe Perches 提交于
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>
-
由 Sean Christopherson 提交于
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>
-
由 Joe Perches 提交于
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>
-
由 Joe Perches 提交于
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>
-
由 Brendan Jackman 提交于
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>
-
由 Matteo Croce 提交于
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>
-
由 Joe Perches 提交于
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>
-
由 Joe Perches 提交于
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>
-
- 14 9月, 2019 4 次提交
-
-
由 Masahiro Yamada 提交于
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>
-
由 Masahiro Yamada 提交于
Use the __section() shorthand. This avoids escaping double-quotes, and improves the readability. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
This makes *.mod.c much more readable. I confirmed depmod still produced the same modules.dep file. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
Arnd Bergmann reported false-positive modpost warnings detected by his randconfig testing of linux-next. Actually, this happens under the combination of CONFIG_MODVERSIONS and CONFIG_TRIM_UNUSED_KSYMS since commit 15bfc234 ("modpost: check for static EXPORT_SYMBOL* functions"). For example, arch/arm/config/multi_v7_defconfig + CONFIG_MODVERSIONS + CONFIG_TRIM_UNUSED_KSYMS produces the following false-positives: WARNING: "__lshrdi3" [vmlinux] is a static (unknown) WARNING: "__ashrdi3" [vmlinux] is a static (unknown) WARNING: "__aeabi_lasr" [vmlinux] is a static (unknown) WARNING: "__aeabi_llsr" [vmlinux] is a static (unknown) WARNING: "ftrace_set_clr_event" [vmlinux] is a static (unknown) WARNING: "__muldi3" [vmlinux] is a static (unknown) WARNING: "__aeabi_ulcmp" [vmlinux] is a static (unknown) WARNING: "__ucmpdi2" [vmlinux] is a static (unknown) WARNING: "__aeabi_lmul" [vmlinux] is a static (unknown) WARNING: "__bswapsi2" [vmlinux] is a static (unknown) WARNING: "__bswapdi2" [vmlinux] is a static (unknown) WARNING: "__ashldi3" [vmlinux] is a static (unknown) WARNING: "__aeabi_llsl" [vmlinux] is a static (unknown) The root cause of the problem is not in the modpost, but in the implementation of CONFIG_TRIM_UNUSED_KSYMS. If there is at least one untrimmed symbol in the file, genksyms is invoked to calculate CRC of *all* the exported symbols in that file even if some of them have been trimmed due to no caller existing. As a result, .tmp_*.ver files contain CRC of trimmed symbols, thus unneeded, orphan __crc* symbols are added to objects. It had been harmless until recently. With commit 15bfc234 ("modpost: check for static EXPORT_SYMBOL* functions"), it is now harmful because the bogus __crc* symbols make modpost call sym_update_crc() to add the symbols to the hash table, but there is no one that clears the ->is_static member. I gave Fixes to the first commit that uncovered the issue, but the potential problem has long existed since commit f2355416 ("export.h: allow for per-symbol configurable EXPORT_SYMBOL()"). Fixes: 15bfc234 ("modpost: check for static EXPORT_SYMBOL* functions") Reported-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Tested-by: NArnd Bergmann <arnd@arndb.de>
-
- 10 9月, 2019 3 次提交
-
-
由 Matthias Maennich 提交于
A script that uses the '<module>.ns_deps' files generated by modpost to automatically add the required symbol namespace dependencies to each module. Usage: 1) Move some symbols to a namespace with EXPORT_SYMBOL_NS() or define DEFAULT_SYMBOL_NAMESPACE 2) Run 'make' (or 'make modules') and get warnings about modules not importing that namespace. 3) Run 'make nsdeps' to automatically add required import statements to said modules. This makes it easer for subsystem maintainers to introduce and maintain symbol namespaces into their codebase. Co-developed-by: NMartijn Coenen <maco@android.com> Signed-off-by: NMartijn Coenen <maco@android.com> Acked-by: NJulia Lawall <julia.lawall@lip6.fr> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NMatthias Maennich <maennich@google.com> Signed-off-by: NJessica Yu <jeyu@kernel.org>
-
由 Matthias Maennich 提交于
This patch adds an option to modpost to generate a <module>.ns_deps file per module, containing the namespace dependencies for that module. E.g. if the linked module my-module.ko would depend on the symbol myfunc.MY_NS in the namespace MY_NS, the my-module.ns_deps file created by modpost would contain the entry MY_NS to express the namespace dependency of my-module imposed by using the symbol myfunc. These files can subsequently be used by static analysis tools (like coccinelle scripts) to address issues with missing namespace imports. A later patch of this series will introduce such a script 'nsdeps' and a corresponding make target to automatically add missing MODULE_IMPORT_NS() definitions to the module's sources. For that it uses the information provided in the generated .ns_deps files. Co-developed-by: NMartijn Coenen <maco@android.com> Signed-off-by: NMartijn Coenen <maco@android.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NMatthias Maennich <maennich@google.com> Signed-off-by: NJessica Yu <jeyu@kernel.org>
-
由 Matthias Maennich 提交于
Add support for symbols that are exported into namespaces. For that, extract any namespace suffix from the symbol name. In addition, emit a warning whenever a module refers to an exported symbol without explicitly importing the namespace that it is defined in. This patch consistently adds the namespace suffix to symbol names exported into Module.symvers. Example warning emitted by modpost in case of the above violation: WARNING: module ums-usbat uses symbol usb_stor_resume from namespace USB_STORAGE, but does not import it. Co-developed-by: NMartijn Coenen <maco@android.com> Signed-off-by: NMartijn Coenen <maco@android.com> Reviewed-by: NJoel Fernandes (Google) <joel@joelfernandes.org> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NMatthias Maennich <maennich@google.com> Signed-off-by: NJessica Yu <jeyu@kernel.org>
-
- 09 9月, 2019 1 次提交
-
-
由 Masahiro Yamada 提交于
GCC and Clang have different policy for -Wunused-function; GCC does not warn unused static inline functions at all whereas Clang does if they are defined in source files instead of included headers although it has been suppressed since commit abb2ea7d ("compiler, clang: suppress warning for unused static inline functions"). We often miss to delete unused functions where 'static inline' is used in *.c files since there is no tool to detect them. Unused code remains until somebody notices. For example, commit 075ddd75 ("regulator: core: remove unused rdev_get_supply()"). Let's remove __maybe_unused from the inline macro to allow Clang to start finding unused static inline functions. For now, we do this only for W=1 build since it is not a good idea to sprinkle warnings for the normal build (e.g. 35 warnings for arch/x86/configs/x86_64_defconfig). My initial attempt was to add -Wno-unused-function for no W= build (https://lore.kernel.org/patchwork/patch/1120594/) Nathan Chancellor pointed out that would weaken Clang's checks since we would no longer get -Wunused-function without W=1. It is true GCC would catch unused static non-inline functions, but it would weaken Clang as a standalone compiler, at least. Hence, here is a counter implementation. The current problem is, W=... only controls compiler flags, which are globally effective. There is no way to address only 'static inline' functions. This commit defines KBUILD_EXTRA_WARN[123] corresponding to W=[123]. When KBUILD_EXTRA_WARN1 is defined, __maybe_unused is omitted from the 'inline' macro. The new macro __inline_maybe_unused makes the code a bit uglier, so I hope we can remove it entirely after fixing most of the warnings. If you contribute to code clean-up, please run "make CC=clang W=1" and check -Wunused-function warnings. You will find lots of unused functions. Some of them are false-positives because the call-sites are disabled by #ifdef. I do not like to abuse the inline keyword for suppressing unused-function warnings because it is intended to be a hint for the compiler optimization. I prefer #ifdef around the definition, or __maybe_unused if #ifdef would make the code too ugly. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: NNathan Chancellor <natechancellor@gmail.com> Tested-by: NNathan Chancellor <natechancellor@gmail.com>
-
- 07 9月, 2019 1 次提交
-
-
由 Andrii Nakryiko 提交于
${@:2} is BASH-specific extension, which makes link-vmlinux.sh rely on BASH. Use shift and ${@} instead to fix this issue. Reported-by: NStephen Rothwell <sfr@canb.auug.org.au> Fixes: 341dfcf8 ("btf: expose BTF info through sysfs") Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NAndrii Nakryiko <andriin@fb.com> Acked-by: NYonghong Song <yhs@fb.com> Reviewed-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
-
- 06 9月, 2019 3 次提交
-
-
由 Masahiro Yamada 提交于
KBUILD_ENABLE_EXTRA_GCC_CHECKS started as a switch to add extra warning options for GCC, but now it is a historical misnomer since we use it also for Clang, DTC, and even kernel-doc. Rename it to more sensible, shorter KBUILD_EXTRA_WARN. For the backward compatibility, KBUILD_ENABLE_EXTRA_GCC_CHECKS is still supported (but not advertised in the documentation). I also fixed up 'make help', and updated the documentation. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: NNathan Chancellor <natechancellor@gmail.com> Reviewed-by: NNick Desaulniers <ndesaulniers@google.com> Reviewed-by: NSedat Dilek <sedat.dilek@gmail.com>
-
由 Masahiro Yamada 提交于
Instead of the warning-[123] magic, let's accumulate compiler options to KBUILD_CFLAGS directly as the top Makefile does. I think this makes it easier to understand what is going on in this file. This commit slightly changes the behavior, I think all of which are OK. [1] Currently, cc-option calls are needlessly evaluated. For example, warning-3 += $(call cc-option, -Wpacked-bitfield-compat) needs evaluating only when W=3, but it is actually evaluated for W=1, W=2 as well. With this commit, only relevant cc-option calls will be evaluated. This is a slight optimization. [2] Currently, unsupported level like W=4 is checked by: $(error W=$(KBUILD_ENABLE_EXTRA_GCC_CHECKS) is unknown) This will no longer be checked, but I do not think it is a big deal. [3] Currently, 4 Clang warnings (Winitializer-overrides, Wformat, Wsign-compare, Wformat-zero-length) are shown by any of W=1, W=2, and W=3. With this commit, they will be warned only by W=1. I think this is a more correct behavior since each warning belongs to only one group. For understanding this commit correctly: We have 3 warning groups, W=1, W=2, and W=3. You may think W=3 has a higher level than W=1, but they are actually independent. If you like, you can combine them like W=13. To enable all the warnings, you can pass W=123. It is shown by 'make help', but not noticed much. Since we support W= combination, there should not exist intersection among the three groups. If we enable Winitializer-overrides for W=1, we do not need to for W=2 or W=3. This is the reason why I think the change [3] makes sense. The documentation says -Winitializer-overrides is enabled by default. (https://clang.llvm.org/docs/DiagnosticsReference.html#winitializer-overrides) We negate it by passing -Wno-initializer-overrides for the normal build, but we do not do that for W=1. This means, W=1 effectively enables -Winitializer-overrides by the clang's default. The same for the other three. Add comments in case people are confused with the code. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: NNathan Chancellor <natechancellor@gmail.com> Tested-by: NSedat Dilek <sedat.dilek@gmail.com> Acked-by: NNick Desaulniers <ndesaulniers@google.com> Acked-by: NMiguel Ojeda <miguel.ojeda.sandonis@gmail.com>
-
由 YueHaibing 提交于
When do coccicheck, I get this error: spatch -D report --no-show-diff --very-quiet --cocci-file ./scripts/coccinelle/api/platform_get_irq.cocci --include-headers --dir . -I ./arch/x86/include -I ./arch/x86/include/generated -I ./include -I ./arch/x86/include/uapi -I ./arch/x86/include/generated/uapi -I ./include/uapi -I ./include/generated/uapi --include ./include/linux/kconfig.h --jobs 192 --chunksize 1 minus: parse error: File "./scripts/coccinelle/api/platform_get_irq.cocci", line 24, column 9, charpos = 355 around = '\(', whole content = if ( ret \( < \| <= \) 0 ) In commit e56476897448 ("fpga: Remove dev_err() usage after platform_get_irq()") log, I found the semantic patch, it fix this issue. Fixes: 98051ba2 ("coccinelle: Add script to check for platform_get_irq() excessive prints") Signed-off-by: NYueHaibing <yuehaibing@huawei.com> Reviewed-by: NStephen Boyd <swboyd@chromium.org> Acked-by: NJulia Lawall <julia.lawall@lip6.fr> Link: https://lore.kernel.org/r/20190906033006.17616-1-yuehaibing@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 04 9月, 2019 5 次提交
-
-
由 Guillaume Tucker 提交于
The merge_config.sh script verifies that all the config options have their expected value in the resulting file and prints any issues as warnings. These checks aren't intended to be treated as errors given the current implementation. However, since "set -e" was added, if the grep command to look for a config option does not find it the script will then abort prematurely. Handle the case where the grep exit status is non-zero by setting ACTUAL_VAL to an empty string to restore previous functionality. Fixes: cdfca821 ("merge_config.sh: Check error codes from make") Signed-off-by: NGuillaume Tucker <guillaume.tucker@collabora.com> Acked-by: NJon Hunter <jonathanh@nvidia.com> Tested-by: NJon Hunter <jonathanh@nvidia.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
Kbuild provides per-file compiler flag addition/removal: CFLAGS_<basetarget>.o CFLAGS_REMOVE_<basetarget>.o AFLAGS_<basetarget>.o AFLAGS_REMOVE_<basetarget>.o CPPFLAGS_<basetarget>.lds HOSTCFLAGS_<basetarget>.o HOSTCXXFLAGS_<basetarget>.o The <basetarget> is the filename of the target with its directory and suffix stripped. This syntax comes into a trouble when two files with the same basename appear in one Makefile, for example: obj-y += foo.o obj-y += dir/foo.o CFLAGS_foo.o := <some-flags> Here, the <some-flags> applies to both foo.o and dir/foo.o The real world problem is: scripts/kconfig/util.c scripts/kconfig/lxdialog/util.c Both files are compiled into scripts/kconfig/mconf, but only the latter should be given with the ncurses flags. It is more sensible to use the relative path to the Makefile, like this: obj-y += foo.o CFLAGS_foo.o := <some-flags> obj-y += dir/foo.o CFLAGS_dir/foo.o := <other-flags> At first, I attempted to replace $(basetarget) with $*. The $* variable is replaced with the stem ('%') part in a pattern rule. This works with most of cases, but does not for explicit rules. For example, arch/ia64/lib/Makefile reuses rule_as_o_S in its own explicit rules, so $* will be empty, resulting in ignoring the per-file AFLAGS. I introduced a new variable, target-stem, which can be used also from explicit rules. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Acked-by: NMarc Zyngier <maz@kernel.org>
-
由 Denis Efremov 提交于
Add NOFAIL check for the strndup call, because the function allocates memory and can return NULL. All calls to strdup in modpost are checked with NOFAIL. Signed-off-by: NDenis Efremov <efremov@linux.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Heikki Krogerus 提交于
Since guid_t is the recommended data type for UUIDs in kernel (and I guess uuid_le is meant to be ultimately replaced with it), it should be made available here as well. Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
CONFIG_SHELL falls back to sh when bash is not installed on the system, but nobody is testing such a case since bash is usually installed. So, shell scripts invoked by CONFIG_SHELL are only tested with bash. It makes it difficult to test whether the hashbang #!/bin/sh is real. For example, #!/bin/sh in arch/powerpc/kernel/prom_init_check.sh is false. (I fixed it up) Besides, some shell scripts invoked by CONFIG_SHELL use bash-extension and #!/bin/bash is specified as the hashbang, while CONFIG_SHELL may not always be set to bash. Probably, the right thing to do is to introduce BASH, which is bash by default, and always set CONFIG_SHELL to sh. Replace $(CONFIG_SHELL) with $(BASH) for bash scripts. If somebody tries to add bash-extension to a #!/bin/sh script, it will be caught in testing because /bin/sh is a symlink to dash on some major distributions. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 01 9月, 2019 3 次提交
-
-
由 Matt Helsley 提交于
cleanup() mostly frees/unmaps the malloc'd/privately-mapped copy of the ELF file recordmcount is working on, which is set up in mmap_file(). It also deals with positioning within the pseduo prive-mapping of the file and appending to the ELF file. Split into two steps: mmap_cleanup() for the mapping itself file_append_cleanup() for allocations storing the appended ELF data. Also, move the global variable initializations out of the main, per-object-file loop and nearer to the alloc/init (mmap_file()) and two cleanup functions so we can more clearly see how they're related. Link: http://lkml.kernel.org/r/2a387ac86d133d22c68f57b9933c32bab1d09a2d.1564596289.git.mhelsley@vmware.comSigned-off-by: NMatt Helsley <mhelsley@vmware.com> Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
-
由 Matt Helsley 提交于
Redundant cleanup calls were introduced when transitioning from the old error/success handling via setjmp/longjmp -- the longjmp ensured the cleanup() call only happened once but replacing the success_file()/fail_file() calls with cleanup() meant that multiple cleanup() calls can happen as we return from function calls. In do_file(), looking just before and after the "goto out" jumps we can see that multiple cleanups() are being performed. We remove cleanup() calls from the nested functions because it makes the code easier to review -- the resources being cleaned up are generally allocated and initialized in the callers so freeing them there makes more sense. Other redundant cleanup() calls: mmap_file() is only called from do_file() and, if mmap_file() fails, then we goto out and do cleanup() there too. write_file() is only called from do_file() and do_file() calls cleanup() unconditionally after returning from write_file() therefore the cleanup() calls in write_file() are not necessary. find_secsym_ndx(), called from do_func()'s for-loop, when we are cleaning up here it's obvious that we break out of the loop and do another cleanup(). __has_rel_mcount() is called from two parts of do_func() and calls cleanup(). In theory we move them into do_func(), however these in turn prove redundant so another simplification step removes them as well. Link: http://lkml.kernel.org/r/de197e17fc5426623a847ea7cf3a1560a7402a4b.1564596289.git.mhelsley@vmware.comSigned-off-by: NMatt Helsley <mhelsley@vmware.com> Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
-
由 Matt Helsley 提交于
Fix up the whitespace irregularity in the ELF switch blocks. Swapping the initial value of gpfx allows us to simplify all but one of the one-line switch cases even further. Link: http://lkml.kernel.org/r/647f21f43723d3e831cedd3238c893db03eea6f0.1564596289.git.mhelsley@vmware.comSigned-off-by: NMatt Helsley <mhelsley@vmware.com> Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
-