summaryrefslogtreecommitdiffstats
path: root/scripts
Commit message (Collapse)AuthorAgeFilesLines
* bpf: Support llvm-objcopy for vmlinux BTFFangrui Song2020-06-171-14/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 90ceddcb495008ac8ba7a3dce297841efcd7d584 upstream. Simplify gen_btf logic to make it work with llvm-objcopy. The existing 'file format' and 'architecture' parsing logic is brittle and does not work with llvm-objcopy/llvm-objdump. 'file format' output of llvm-objdump>=11 will match GNU objdump, but 'architecture' (bfdarch) may not. .BTF in .tmp_vmlinux.btf is non-SHF_ALLOC. Add the SHF_ALLOC flag because it is part of vmlinux image used for introspection. C code can reference the section via linker script defined __start_BTF and __stop_BTF. This fixes a small problem that previous .BTF had the SHF_WRITE flag (objcopy -I binary -O elf* synthesized .data). Additionally, `objcopy -I binary` synthesized symbols _binary__btf_vmlinux_bin_start and _binary__btf_vmlinux_bin_stop (not used elsewhere) are replaced with more commonplace __start_BTF and __stop_BTF. Add 2>/dev/null because GNU objcopy (but not llvm-objcopy) warns "empty loadable segment detected at vaddr=0xffffffff81000000, is this intentional?" We use a dd command to change the e_type field in the ELF header from ET_EXEC to ET_REL so that lld will accept .btf.vmlinux.bin.o. Accepting ET_EXEC as an input file is an extremely rare GNU ld feature that lld does not intend to support, because this is error-prone. The output section description .BTF in include/asm-generic/vmlinux.lds.h avoids potential subtle orphan section placement issues and suppresses --orphan-handling=warn warnings. Fixes: df786c9b9476 ("bpf: Force .BTF section start to zero when dumping from vmlinux") Fixes: cb0cc635c7a9 ("powerpc: Include .BTF section") Reported-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Fangrui Song <maskray@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Tested-by: Stanislav Fomichev <sdf@google.com> Tested-by: Andrii Nakryiko <andriin@fb.com> Reviewed-by: Stanislav Fomichev <sdf@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Link: https://github.com/ClangBuiltLinux/linux/issues/871 Link: https://lore.kernel.org/bpf/20200318222746.173648-1-maskray@google.com Signed-off-by: Maria Teguiani <teguiani@google.com> Tested-by: Matthias Maennich <maennich@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kbuild: Remove debug info from kallsyms linkingKees Cook2020-05-271-9/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit af73d78bd384aa9b8789aa6e7ddbb165f971276f ] When CONFIG_DEBUG_INFO is enabled, the two kallsyms linking steps spend time collecting and writing the dwarf sections to the temporary output files. kallsyms does not need this information, and leaving it off halves their linking time. This is especially noticeable without CONFIG_DEBUG_INFO_REDUCED. The BTF linking stage, however, does still need those details. Refactor the BTF and kallsyms generation stages slightly for more regularized temporary names. Skip debug during kallsyms links. Additionally move "info BTF" to the correct place since commit 8959e39272d6 ("kbuild: Parameterize kallsyms generation and correct reporting"), which added "info LD ..." to vmlinux_link calls. For a full debug info build with BTF, my link time goes from 1m06s to 0m54s, saving about 12 seconds, or 18%. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/202003031814.4AEA3351@keescook Signed-off-by: Sasha Levin <sashal@kernel.org>
* scripts/gdb: repair rb_first() and rb_last()Aymeric Agon-Rambosson2020-05-271-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 50e36be1fb9572b2e4f2753340bdce3116bf2ce7 ] The current implementations of the rb_first() and rb_last() gdb functions have a variable that references itself in its instanciation, which causes the function to throw an error if a specific condition on the argument is met. The original author rather intended to reference the argument and made a typo. Referring the argument instead makes the function work as intended. Signed-off-by: Aymeric Agon-Rambosson <aymeric.agon@yandex.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: Nikolay Borisov <n.borisov.lkml@gmail.com> Cc: Jackie Liu <liuyun01@kylinos.cn> Cc: Jason Wessel <jason.wessel@windriver.com> Link: http://lkml.kernel.org/r/20200427051029.354840-1-aymeric.agon@yandex.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* gcc-common.h: Update for GCC 10Frédéric Pierret (fepitre)2020-05-272-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit c7527373fe28f97d8a196ab562db5589be0d34b9 ] Remove "params.h" include, which has been dropped in GCC 10. Remove is_a_helper() macro, which is now defined in gimple.h, as seen when running './scripts/gcc-plugin.sh g++ g++ gcc': In file included from <stdin>:1: ./gcc-plugins/gcc-common.h:852:13: error: redefinition of ‘static bool is_a_helper<T>::test(U*) [with U = const gimple; T = const ggoto*]’ 852 | inline bool is_a_helper<const ggoto *>::test(const_gimple gs) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from ./gcc-plugins/gcc-common.h:125, from <stdin>:1: /usr/lib/gcc/x86_64-redhat-linux/10/plugin/include/gimple.h:1037:1: note: ‘static bool is_a_helper<T>::test(U*) [with U = const gimple; T = const ggoto*]’ previously declared here 1037 | is_a_helper <const ggoto *>::test (const gimple *gs) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ Add -Wno-format-diag to scripts/gcc-plugins/Makefile to avoid meaningless warnings from error() formats used by plugins: scripts/gcc-plugins/structleak_plugin.c: In function ‘int plugin_init(plugin_name_args*, plugin_gcc_version*)’: scripts/gcc-plugins/structleak_plugin.c:253:12: warning: unquoted sequence of 2 consecutive punctuation characters ‘'-’ in format [-Wformat-diag] 253 | error(G_("unknown option '-fplugin-arg-%s-%s'"), plugin_name, argv[i].key); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Frédéric Pierret (fepitre) <frederic.pierret@qubes-os.org> Link: https://lore.kernel.org/r/20200407113259.270172-1-frederic.pierret@qubes-os.org [kees: include -Wno-format-diag for plugin builds] Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* scripts/decodecode: fix trapping instruction formattingIvan Delalande2020-05-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | commit e08df079b23e2e982df15aa340bfbaf50f297504 upstream. If the trapping instruction contains a ':', for a memory access through segment registers for example, the sed substitution will insert the '*' marker in the middle of the instruction instead of the line address: 2b: 65 48 0f c7 0f cmpxchg16b %gs:*(%rdi) <-- trapping instruction I started to think I had forgotten some quirk of the assembly syntax before noticing that it was actually coming from the script. Fix it to add the address marker at the right place for these instructions: 28: 49 8b 06 mov (%r14),%rax 2b:* 65 48 0f c7 0f cmpxchg16b %gs:(%rdi) <-- trapping instruction 30: 0f 94 c0 sete %al Fixes: 18ff44b189e2 ("scripts/decodecode: make faulting insn ptr more robust") Signed-off-by: Ivan Delalande <colona@arista.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Borislav Petkov <bp@suse.de> Link: http://lkml.kernel.org/r/20200419223653.GA31248@visor Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* scripts/config: allow colons in option strings for sedJeremie Francois (on alpha)2020-05-101-1/+4
| | | | | | | | | | | | | | [ Upstream commit e461bc9f9ab105637b86065d24b0b83f182d477c ] Sed broke on some strings as it used colon as a separator. I made it more robust by using \001, which is legit POSIX AFAIK. E.g. ./config --set-str CONFIG_USBNET_DEVADDR "de:ad:be:ef:00:01" failed with: sed: -e expression #1, char 55: unknown option to `s' Signed-off-by: Jeremie Francois (on alpha) <jeremie.francois@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* kbuild: fix DT binding schema rule again to avoid needless rebuildsMasahiro Yamada2020-05-021-1/+1
| | | | | | | | | | | | | | | | | | commit 3d4b2238684ac919394eba7fb51bb7eeeec6ab57 upstream. Since commit 7a0496056064 ("kbuild: fix DT binding schema rule to detect command line changes"), this rule is every time re-run even if you change nothing. cmd_dtc takes one additional parameter to pass to the -O option of dtc. We need to pass 'yaml' to if_changed_rule. Otherwise, cmd-check invoked from if_changed_rule is false positive. Fixes: 7a0496056064 ("kbuild: fix DT binding schema rule to detect command line changes") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kconfig: qconf: Fix a few alignment issuesMauro Carvalho Chehab2020-04-291-6/+7
| | | | | | | | | | [ Upstream commit 60969f02f07ae1445730c7b293c421d179da729c ] There are a few items with wrong alignments. Solve them. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* kconfig: introduce m32-flag and m64-flagMasahiro Yamada2020-04-081-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 8cc4fd73501d9f1370c3eebb70cfe8cc9e24062b ] When a compiler supports multiple architectures, some compiler features can be dependent on the target architecture. This is typical for Clang, which supports multiple LLVM backends. Even for GCC, we need to take care of biarch compiler cases. It is not a problem when we evaluate cc-option in Makefiles because cc-option is tested against the flag in question + $(KBUILD_CFLAGS). The cc-option in Kconfig, on the other hand, does not accumulate tested flags. Due to this simplification, it could potentially test cc-option against a different target. At first, Kconfig always evaluated cc-option against the host architecture. Since commit e8de12fb7cde ("kbuild: Check for unknown options with cc-option usage in Kconfig and clang"), in case of cross-compiling with Clang, the target triple is correctly passed to Kconfig. The case with biarch GCC (and native build with Clang) is still not handled properly. We need to pass some flags to specify the target machine bit. Due to the design, all the macros in Kconfig are expanded in the parse stage, where we do not know the target bit size yet. For example, arch/x86/Kconfig allows a user to toggle CONFIG_64BIT. If a compiler flag -foo depends on the machine bit, it must be tested twice, one with -m32 and the other with -m64. However, -m32/-m64 are not always recognized. So, this commits adds m64-flag and m32-flag macros. They expand to -m32, -m64, respectively if supported. Or, they expand to an empty string if unsupported. The typical usage is like this: config FOO bool default $(cc-option,$(m64-flag) -foo) if 64BIT default $(cc-option,$(m32-flag) -foo) This is clumsy, but there is no elegant way to handle this in the current static macro expansion. There was discussion for static functions vs dynamic functions. The consensus was to go as far as possible with the static functions. (https://lkml.org/lkml/2018/3/2/22) Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: George Spelvin <lkml@sdf.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* scripts/dtc: Remove redundant YYLOC global declarationDirk Mueller2020-04-011-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit e33a814e772cdc36436c8c188d8c42d019fda639 upstream. gcc 10 will default to -fno-common, which causes this error at link time: (.text+0x0): multiple definition of `yylloc'; dtc-lexer.lex.o (symbol from plugin):(.text+0x0): first defined here This is because both dtc-lexer as well as dtc-parser define the same global symbol yyloc. Before with -fcommon those were merged into one defintion. The proper solution would be to to mark this as "extern", however that leads to: dtc-lexer.l:26:16: error: redundant redeclaration of 'yylloc' [-Werror=redundant-decls] 26 | extern YYLTYPE yylloc; | ^~~~~~ In file included from dtc-lexer.l:24: dtc-parser.tab.h:127:16: note: previous declaration of 'yylloc' was here 127 | extern YYLTYPE yylloc; | ^~~~~~ cc1: all warnings being treated as errors which means the declaration is completely redundant and can just be dropped. Signed-off-by: Dirk Mueller <dmueller@suse.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> [robh: cherry-pick from upstream] Cc: stable@vger.kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* modpost: move the namespace field in Module.symvers lastJessica Yu2020-03-252-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 5190044c2965514a973184ca68ef5fad57a24670 upstream. In order to preserve backwards compatability with kmod tools, we have to move the namespace field in Module.symvers last, as the depmod -e -E option looks at the first three fields in Module.symvers to check symbol versions (and it's expected they stay in the original order of crc, symbol, module). In addition, update an ancient comment above read_dump() in modpost that suggested that the export type field in Module.symvers was optional. I suspect that there were historical reasons behind that comment that are no longer accurate. We have been unconditionally printing the export type since 2.6.18 (commit bd5cbcedf44), which is over a decade ago now. Fix up read_dump() to treat each field as non-optional. I suspect the original read_dump() code treated the export field as optional in order to support pre <= 2.6.18 Module.symvers (which did not have the export type field). Note that although symbol namespaces are optional, the field will not be omitted from Module.symvers if a symbol does not have a namespace. In this case, the field will simply be empty and the next delimiter or end of line will follow. Cc: stable@vger.kernel.org Fixes: cb9b55d21fe0 ("modpost: add support for symbol namespaces") Tested-by: Matthias Maennich <maennich@google.com> Reviewed-by: Matthias Maennich <maennich@google.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jessica Yu <jeyu@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kbuild: Disable -Wpointer-to-enum-castNathan Chancellor2020-03-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | commit 82f2bc2fcc0160d6f82dd1ac64518ae0a4dd183f upstream. Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when casting to enums. The kernel does this in certain places, such as device tree matches to set the version of the device being used, which allows the kernel to avoid using a gigantic union. https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428 https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402 https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264 To avoid a ton of false positive warnings, disable this particular part of the warning, which has been split off into a separate diagnostic so that the entire warning does not need to be turned off for clang. It will be visible under W=1 in case people want to go about fixing these easily and enabling the warning treewide. Cc: stable@vger.kernel.org Link: https://github.com/ClangBuiltLinux/linux/issues/887 Link: https://github.com/llvm/llvm-project/commit/2a41b31fcdfcb67ab7038fc2ffb606fd50b83a84 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* parse-maintainers: Mark as executableJonathan Neuschäfer2020-03-251-0/+0
| | | | | | | | | | [ Upstream commit 611d61f9ac99dc9e1494473fb90117a960a89dfa ] This makes the script more convenient to run. Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* kbuild: move headers_check rule to usr/include/MakefileMasahiro Yamada2020-03-051-18/+0
| | | | | | | | | | | | | | | | | commit 7ecaf069da52e472d393f03e79d721aabd724166 upstream. Currently, some sanity checks for uapi headers are done by scripts/headers_check.pl, which is wired up to the 'headers_check' target in the top Makefile. It is true compiling headers has better test coverage, but there are still several headers excluded from the compile test. I like to keep headers_check.pl for a while, but we can delete a lot of code by moving the build rule to usr/include/Makefile. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kbuild: remove header compile testMasahiro Yamada2020-03-052-23/+0
| | | | | | | | | | | | | | | | | | | | | | commit fcbb8461fd2376ba3782b5b8bd440c929b8e4980 upstream. There are both positive and negative options about this feature. At first, I thought it was a good idea, but actually Linus stated a negative opinion (https://lkml.org/lkml/2019/9/29/227). I admit it is ugly and annoying. The baseline I'd like to keep is the compile-test of uapi headers. (Otherwise, kernel developers have no way to ensure the correctness of the exported headers.) I will maintain a small build rule in usr/include/Makefile. Remove the other header test functionality. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> [ added to 5.4.y due to start of build warnings from backported patches because of this feature - gregkh] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kbuild: fix DT binding schema rule to detect command line changesMasahiro Yamada2020-03-051-2/+2
| | | | | | | | | | | | | | | | | | | | commit 7a04960560640ac5b0b89461f7757322b57d0c7a upstream. This if_change_rule is not working properly; it cannot detect any command line change. The reason is because cmd-check in scripts/Kbuild.include compares $(cmd_$@) and $(cmd_$1), but cmd_dtc_dt_yaml does not exist here. For if_change_rule to work properly, the stem part of cmd_* and rule_* must match. Because this cmd_and_fixdep invokes cmd_dtc, this rule must be named rule_dtc. Fixes: 4f0e3a57d6eb ("kbuild: Add support for DT binding schema checks") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* bpf, btf: Always output invariant hit in pahole DWARF to BTF transformChris Down2020-02-241-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 2a67a6ccb01f21b854715d86ff6432a18b97adb3 ] When trying to compile with CONFIG_DEBUG_INFO_BTF enabled, I got this error: % make -s Failed to generate BTF for vmlinux Try to disable CONFIG_DEBUG_INFO_BTF make[3]: *** [vmlinux] Error 1 Compiling again without -s shows the true error (that pahole is missing), but since this is fatal, we should show the error unconditionally on stderr as well, not silence it using the `info` function. With this patch: % make -s BTF: .tmp_vmlinux.btf: pahole (pahole) is not available Failed to generate BTF for vmlinux Try to disable CONFIG_DEBUG_INFO_BTF make[3]: *** [vmlinux] Error 1 Signed-off-by: Chris Down <chris@chrisdown.name> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20200122000110.GA310073@chrisdown.name Signed-off-by: Sasha Levin <sashal@kernel.org>
* kbuild: use -S instead of -E for precise cc-option test in KconfigMasahiro Yamada2020-02-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 3bed1b7b9d79ca40e41e3af130931a3225e951a3 ] Currently, -E (stop after the preprocessing stage) is used to check whether the given compiler flag is supported. While it is faster than -S (or -c), it can be false-positive. You need to run the compilation proper to check the flag more precisely. For example, -E and -S disagree about the support of "--param asan-instrument-allocas=1". $ gcc -Werror --param asan-instrument-allocas=1 -E -x c /dev/null -o /dev/null $ echo $? 0 $ gcc -Werror --param asan-instrument-allocas=1 -S -x c /dev/null -o /dev/null cc1: error: invalid --param name ‘asan-instrument-allocas’; did you mean ‘asan-instrument-writes’? $ echo $? 1 Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* kbuild: remove *.tmp file when filechk failsMasahiro Yamada2020-02-241-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 88fe89a47153facd8cb2d06d5c8727f7224c43c2 ] Bartosz Golaszewski reports that when "make {menu,n,g,x}config" fails due to missing packages, a temporary file is left over, which is not ignored by git. For example, if GTK+ is not installed: $ make gconfig * * Unable to find the GTK+ installation. Please make sure that * the GTK+ 2.0 development package is correctly installed. * You need gtk+-2.0 gmodule-2.0 libglade-2.0 * scripts/kconfig/Makefile:208: recipe for target 'scripts/kconfig/gconf-cfg' failed make[1]: *** [scripts/kconfig/gconf-cfg] Error 1 Makefile:567: recipe for target 'gconfig' failed make: *** [gconfig] Error 2 $ git status HEAD detached at v5.4 Untracked files: (use "git add <file>..." to include in what will be committed) scripts/kconfig/gconf-cfg.tmp nothing added to commit but untracked files present (use "git add" to track) This is because the check scripts are run with filechk, which misses to clean up the temporary file on failure. When the line { $(filechk_$(1)); } > $@.tmp; ... fails, it exits immediately due to the 'set -e'. Use trap to make sure to delete the temporary file on exit. For extra safety, I replaced $@.tmp with $(dot-target).tmp to make it a hidden file. Reported-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* kconfig: fix broken dependency in randconfig-generated .configMasahiro Yamada2020-02-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit c8fb7d7e48d11520ad24808cfce7afb7b9c9f798 ] Running randconfig on arm64 using KCONFIG_SEED=0x40C5E904 (e.g. on v5.5) produces the .config with CONFIG_EFI=y and CONFIG_CPU_BIG_ENDIAN=y, which does not meet the !CONFIG_CPU_BIG_ENDIAN dependency. This is because the user choice for CONFIG_CPU_LITTLE_ENDIAN vs CONFIG_CPU_BIG_ENDIAN is set by randomize_choice_values() after the value of CONFIG_EFI is calculated. When this happens, the has_changed flag should be set. Currently, it takes the result from the last iteration. It should accumulate all the results of the loop. Fixes: 3b9a19e08960 ("kconfig: loop as long as we changed some symbols in randconfig") Reported-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* scripts/find-unused-docs: Fix massive false positivesGeert Uytterhoeven2020-02-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | commit 1630146db2111412e7524d05d812ff8f2c75977e upstream. scripts/find-unused-docs.sh invokes scripts/kernel-doc to find out if a source file contains kerneldoc or not. However, as it passes the no longer supported "-text" option to scripts/kernel-doc, the latter prints out its help text, causing all files to be considered containing kerneldoc. Get rid of these false positives by removing the no longer supported "-text" option from the scripts/kernel-doc invocation. Cc: stable@vger.kernel.org # 4.16+ Fixes: b05142675310d2ac ("scripts: kernel-doc: get rid of unused output formats") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200127093107.26401-1-geert+renesas@glider.be Signed-off-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ARM: 8950/1: ftrace/recordmcount: filter relocation typesAlex Sverdlin2020-01-291-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 927d780ee371d7e121cea4fc7812f6ef2cea461c upstream. Scenario 1, ARMv7 ================= If code in arch/arm/kernel/ftrace.c would operate on mcount() pointer the following may be generated: 00000230 <prealloc_fixed_plts>: 230: b5f8 push {r3, r4, r5, r6, r7, lr} 232: b500 push {lr} 234: f7ff fffe bl 0 <__gnu_mcount_nc> 234: R_ARM_THM_CALL __gnu_mcount_nc 238: f240 0600 movw r6, #0 238: R_ARM_THM_MOVW_ABS_NC __gnu_mcount_nc 23c: f8d0 1180 ldr.w r1, [r0, #384] ; 0x180 FTRACE currently is not able to deal with it: WARNING: CPU: 0 PID: 0 at .../kernel/trace/ftrace.c:1979 ftrace_bug+0x1ad/0x230() ... CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.116-... #1 ... [<c0314e3d>] (unwind_backtrace) from [<c03115e9>] (show_stack+0x11/0x14) [<c03115e9>] (show_stack) from [<c051a7f1>] (dump_stack+0x81/0xa8) [<c051a7f1>] (dump_stack) from [<c0321c5d>] (warn_slowpath_common+0x69/0x90) [<c0321c5d>] (warn_slowpath_common) from [<c0321cf3>] (warn_slowpath_null+0x17/0x1c) [<c0321cf3>] (warn_slowpath_null) from [<c038ee9d>] (ftrace_bug+0x1ad/0x230) [<c038ee9d>] (ftrace_bug) from [<c038f1f9>] (ftrace_process_locs+0x27d/0x444) [<c038f1f9>] (ftrace_process_locs) from [<c08915bd>] (ftrace_init+0x91/0xe8) [<c08915bd>] (ftrace_init) from [<c0885a67>] (start_kernel+0x34b/0x358) [<c0885a67>] (start_kernel) from [<00308095>] (0x308095) ---[ end trace cb88537fdc8fa200 ]--- ftrace failed to modify [<c031266c>] prealloc_fixed_plts+0x8/0x60 actual: 44:f2:e1:36 ftrace record flags: 0 (0) expected tramp: c03143e9 Scenario 2, ARMv4T ================== ftrace: allocating 14435 entries in 43 pages ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:2029 ftrace_bug+0x204/0x310 CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.5 #1 Hardware name: Cirrus Logic EDB9302 Evaluation Board [<c0010a24>] (unwind_backtrace) from [<c000ecb0>] (show_stack+0x20/0x2c) [<c000ecb0>] (show_stack) from [<c03c72e8>] (dump_stack+0x20/0x30) [<c03c72e8>] (dump_stack) from [<c0021c18>] (__warn+0xdc/0x104) [<c0021c18>] (__warn) from [<c0021d7c>] (warn_slowpath_null+0x4c/0x5c) [<c0021d7c>] (warn_slowpath_null) from [<c0095360>] (ftrace_bug+0x204/0x310) [<c0095360>] (ftrace_bug) from [<c04dabac>] (ftrace_init+0x3b4/0x4d4) [<c04dabac>] (ftrace_init) from [<c04cef4c>] (start_kernel+0x20c/0x410) [<c04cef4c>] (start_kernel) from [<00000000>] ( (null)) ---[ end trace 0506a2f5dae6b341 ]--- ftrace failed to modify [<c000c350>] perf_trace_sys_exit+0x5c/0xe8 actual: 1e:ff:2f:e1 Initializing ftrace call sites ftrace record flags: 0 (0) expected tramp: c000fb24 The analysis for this problem has been already performed previously, refer to the link below. Fix the above problems by allowing only selected reloc types in __mcount_loc. The list itself comes from the legacy recordmcount.pl script. Link: https://lore.kernel.org/lkml/56961010.6000806@pengutronix.de/ Cc: stable@vger.kernel.org Fixes: ed60453fa8f8 ("ARM: 6511/1: ftrace: add ARM support for C version of recordmcount") Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* bpf: Force .BTF section start to zero when dumping from vmlinuxStanislav Fomichev2020-01-261-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit df786c9b947639aedbc7bb44b5dae2a7824af360 upstream. While trying to figure out why fentry_fexit selftest doesn't pass for me (old pahole, broken BTF), I found out that my latest patch can break vmlinux .BTF generation. objcopy preserves section start when doing --only-section, so there is a chance (depending on where pahole inserts .BTF section) to have leading empty zeroes. Let's explicitly force section offset to zero. Before: $ objcopy --set-section-flags .BTF=alloc -O binary \ --only-section=.BTF vmlinux .btf.vmlinux.bin $ xxd .btf.vmlinux.bin | head -n1 00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ After: $ objcopy --change-section-address .BTF=0 \ --set-section-flags .BTF=alloc -O binary \ --only-section=.BTF vmlinux .btf.vmlinux.bin $ xxd .btf.vmlinux.bin | head -n1 00000000: 9feb 0100 1800 0000 0000 0000 80e1 1c00 ................ ^BTF magic As part of this change, I'm also dropping '2>/dev/null' from objcopy invocation to be able to catch possible other issues (objcopy doesn't produce any warnings for me anymore, it did before with --dump-section). Fixes: da5fb18225b4 ("bpf: Support pre-2.25-binutils objcopy for vmlinux BTF") Signed-off-by: Stanislav Fomichev <sdf@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: John Fastabend <john.fastabend@gmail.com> Cc: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20191127225759.39923-1-sdf@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* kbuild/deb-pkg: annotate libelf-dev dependency as :nativeArd Biesheuvel2020-01-171-1/+1
| | | | | | | | | | | | | | | | | | | | [ Upstream commit 8ffdc54b6f4cd718a45802e645bb853e3a46a078 ] Cross compiling the x86 kernel on a non-x86 build machine produces the following error when CONFIG_UNWINDER_ORC is enabled, regardless of whether libelf-dev is installed or not. dpkg-checkbuilddeps: error: Unmet build dependencies: libelf-dev dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting dpkg-buildpackage: warning: (Use -d flag to override.) Since this is a build time dependency for a build tool, we need to depend on the native version of libelf-dev so add the appropriate annotation. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* bpf: Support pre-2.25-binutils objcopy for vmlinux BTFStanislav Fomichev2020-01-171-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit da5fb18225b49b97bb37c51bcbbb2990a507c364 upstream. If vmlinux BTF generation fails, but CONFIG_DEBUG_INFO_BTF is set, .BTF section of vmlinux is empty and kernel will prohibit BPF loading and return "in-kernel BTF is malformed". --dump-section argument to binutils' objcopy was added in version 2.25. When using pre-2.25 binutils, BTF generation silently fails. Convert to --only-section which is present on pre-2.25 binutils. Documentation/process/changes.rst states that binutils 2.21+ is supported, not sure those standards apply to BPF subsystem. v2: * exit and print an error if gen_btf fails (John Fastabend) v3: * resend with Andrii's Acked-by/Tested-by tags Fixes: 341dfcf8d78ea ("btf: expose BTF info through sysfs") Signed-off-by: Stanislav Fomichev <sdf@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Tested-by: Andrii Nakryiko <andriin@fb.com> Acked-by: Andrii Nakryiko <andriin@fb.com> Cc: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20191127161410.57327-1-sdf@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* scripts: package: mkdebian: add missing rsync dependencyEnrico Weigelt, metux IT consult2020-01-121-1/+1
| | | | | | | | | | | | [ Upstream commit a11391b6f50689adb22c65df783e09143fafb794 ] We've missed the dependency to rsync, so build fails on minimal containers. Fixes: 59b2bd05f5f4 ("kbuild: add 'headers' target to build up uapi headers in usr/include") Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* kconfig: don't crash on NULL expressions in expr_eq()Thomas Hebb2020-01-121-0/+7
| | | | | | | | | | | | | [ Upstream commit 272a72103012862e3a24ea06635253ead0b6e808 ] NULL expressions are taken to always be true, as implemented by the expr_is_yes() macro and by several other functions in expr.c. As such, they ought to be valid inputs to expr_eq(), which compares two expressions. Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* gcc-plugins: make it possible to disable CONFIG_GCC_PLUGINS againArnd Bergmann2020-01-091-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit a5b0dc5a46c221725c43bd9b01570239a4cd78b1 upstream. I noticed that randconfig builds with gcc no longer produce a lot of ccache hits, unlike with clang, and traced this back to plugins now being enabled unconditionally if they are supported. I am now working around this by adding export CCACHE_COMPILERCHECK=/usr/bin/size -A %compiler% to my top-level Makefile. This changes the heuristic that ccache uses to determine whether the plugins are the same after a 'make clean'. However, it also seems that being able to just turn off the plugins is generally useful, at least for build testing it adds noticeable overhead but does not find a lot of bugs additional bugs, and may be easier for ccache users than my workaround. Fixes: 9f671e58159a ("security: Create "kernel hardening" config area") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Masahiro Yamada <masahiroy@kernel.org> Link: https://lore.kernel.org/r/20191211133951.401933-1-arnd@arndb.de Cc: stable@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* scripts/kallsyms: fix definitely-lost memory leakMasahiro Yamada2020-01-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 21915eca088dc271c970e8351290e83d938114ac ] build_initial_tok_table() overwrites unused sym_entry to shrink the table size. Before the entry is overwritten, table[i].sym must be freed since it is malloc'ed data. This fixes the 'definitely lost' report from valgrind. I ran valgrind against x86_64_defconfig of v5.4-rc8 kernel, and here is the summary: [Before the fix] LEAK SUMMARY: definitely lost: 53,184 bytes in 2,874 blocks [After the fix] LEAK SUMMARY: definitely lost: 0 bytes in 0 blocks Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* dtc: Use pkg-config to locate libyamlPavel Modilaynen2020-01-041-2/+2
| | | | | | | | | | | | | | | | | | | | [ Upstream commit 067c650c456e758f933aaf87a202f841d34be269 ] Using Makefile's wildcard with absolute path to detect the presence of libyaml results in false-positive detection when cross-compiling e.g. in yocto environment. The latter results in build error: | scripts/dtc/yamltree.o: In function `yaml_propval_int': | yamltree.c: undefined reference to `yaml_sequence_start_event_initialize' | yamltree.c: undefined reference to `yaml_emitter_emit' | yamltree.c: undefined reference to `yaml_scalar_event_initialize' ... Use pkg-config to locate libyaml to address this scenario. Signed-off-by: Pavel Modilaynen <pavel.modilaynen@axis.com> [robh: silence stderr] Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* Merge tag 'arm64-fixes' of ↵Linus Torvalds2019-11-151-4/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fix from Will Deacon: "One trivial fix for -rc8/final that ensures that the script used to detect RELR relocation support in the toolchain works correctly when $CC contains quotes. Although it fails safely (by failing to detect the support when it exists), it would be nice to have this fixed in 5.4 given that it was only introduced in the last merge window. Summary: - Handle CC variables containing quotes in tools-support-relr.sh script" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: scripts/tools-support-relr.sh: un-quote variables
| * scripts/tools-support-relr.sh: un-quote variablesIlie Halip2019-11-131-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the CC variable contains quotes, e.g. when using ccache (make CC="ccache <compiler>"), this script always fails, so CONFIG_RELR is never enabled, even when the toolchain supports this feature. Removing the /dev/null redirect and invoking the script manually shows the issue: $ CC='/usr/bin/ccache clang' ./scripts/tools-support-relr.sh ./scripts/tools-support-relr.sh: 7: ./scripts/tools-support-relr.sh: /usr/bin/ccache clang: not found Fix this by un-quoting the variables. Before: $ make ARCH=arm64 CC='/usr/bin/ccache clang' LD=ld.lld \ NM=llvm-nm OBJCOPY=llvm-objcopy defconfig $ grep RELR .config CONFIG_ARCH_HAS_RELR=y With this change: $ make ARCH=arm64 CC='/usr/bin/ccache clang' LD=ld.lld \ NM=llvm-nm OBJCOPY=llvm-objcopy defconfig $ grep RELR .config CONFIG_TOOLS_SUPPORT_RELR=y CONFIG_ARCH_HAS_RELR=y CONFIG_RELR=y Fixes: 5cf896fb6be3 ("arm64: Add support for relocating the kernel with RELR relocations") Reported-by: Dmitry Golovin <dima@golovin.in> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> Link: https://github.com/ClangBuiltLinux/linux/issues/769 Cc: Peter Collingbourne <pcc@google.com> Signed-off-by: Ilie Halip <ilie.halip@gmail.com> Signed-off-by: Will Deacon <will@kernel.org>
* | Merge tag 'modules-for-v5.4-rc7' of ↵Linus Torvalds2019-11-081-3/+3
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux Pull modules fix from Jessica Yu: "Fix `make nsdeps` for modules composed of multiple source files. Since $mod_source_files was not in quotes in the call to generate_deps_for_ns(), not all the source files for a module were being passed to spatch" * tag 'modules-for-v5.4-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux: scripts/nsdeps: make sure to pass all module source files to spatch
| * | scripts/nsdeps: make sure to pass all module source files to spatchJessica Yu2019-11-051-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Matthias Maennich <maennich@google.com> Signed-off-by: Jessica Yu <jeyu@kernel.org>
* | | scripts/gdb: fix debugging modules compiled with hot/cold partitioningIlya Leoshkevich2019-11-061-1/+2
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.com Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Jan 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: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | Merge tag 'modules-for-v5.4-rc5' of ↵Linus Torvalds2019-10-253-20/+42
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux Pull modules fixes from Jessica Yu: - Revert __ksymtab_$namespace.$symbol naming scheme back to __ksymtab_$symbol, as it was causing issues with depmod. Instead, have modpost extract a symbol's namespace from __kstrtabns and __ksymtab_strings. - Fix `make nsdeps` for out of tree kernel builds (make O=...) caused by unescaped '/'. Use a different sed delimiter to avoid this problem. * tag 'modules-for-v5.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux: scripts/nsdeps: use alternative sed delimiter symbol namespaces: revert to previous __ksymtab name scheme modpost: make updating the symbol namespace explicit modpost: delegate updating namespaces to separate function
| * | scripts/nsdeps: use alternative sed delimiterJessica Yu2019-10-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Matthias Maennich <maennich@google.com> Tested-by: Matthias Maennich <maennich@google.com> Signed-off-by: Jessica Yu <jeyu@kernel.org>
| * | symbol namespaces: revert to previous __ksymtab name schemeMatthias Maennich2019-10-182-15/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: 8651ec01daed ("module: add support for symbol namespaces.") Reported-by: Stefan Wahren <stefan.wahren@i2se.com> Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Will Deacon <will@kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Matthias Maennich <maennich@google.com> Signed-off-by: Jessica Yu <jeyu@kernel.org>
| * | modpost: make updating the symbol namespace explicitMatthias Maennich2019-10-181-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Will Deacon <will@kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Matthias Maennich <maennich@google.com> Signed-off-by: Jessica Yu <jeyu@kernel.org>
| * | modpost: delegate updating namespaces to separate functionMatthias Maennich2019-10-181-3/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Will Deacon <will@kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Matthias Maennich <maennich@google.com> Signed-off-by: Jessica Yu <jeyu@kernel.org>
* | | Merge tag 'kbuild-fixes-v5.4-2' of ↵Linus Torvalds2019-10-201-1/+1
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull more Kbuild fixes from Masahiro Yamada: - fix a bashism of setlocalversion - do not use the too new --sort option of tar * tag 'kbuild-fixes-v5.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kheaders: substituting --sort in archive creation scripts: setlocalversion: fix a bashism kbuild: update comment about KBUILD_ALLDIRS
| * | | scripts: setlocalversion: fix a bashismRandy Dunlap2019-10-151-1/+1
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: 38b3439d84f4 ("setlocalversion: update mercurial tag parsing") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Mike Crowe <mcrowe@zipitwireless.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* | | scripts/gdb: fix debugging modules on s390Ilya Leoshkevich2019-10-191-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.com Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Jan 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: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | | scripts/gdb: fix lx-dmesg when CONFIG_PRINTK_CALLER is setJoel Colledge2019-10-192-16/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.com Signed-off-by: Joel Colledge <joel.colledge@linbit.com> Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | | coccinelle: api/devm_platform_ioremap_resource: remove useless scriptAlexandre Belloni2019-10-171-60/+0
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | Merge tag 'trace-v5.4-rc2' of ↵Linus Torvalds2019-10-131-4/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull tracing fixes from Steven Rostedt: "A few tracing fixes: - Remove lockdown from tracefs itself and moved it to the trace directory. Have the open functions there do the lockdown checks. - Fix a few races with opening an instance file and the instance being deleted (Discovered during the lockdown updates). Kept separate from the clean up code such that they can be backported to stable easier. - Clean up and consolidated the checks done when opening a trace file, as there were multiple checks that need to be done, and it did not make sense having them done in each open instance. - Fix a regression in the record mcount code. - Small hw_lat detector tracer fixes. - A trace_pipe read fix due to not initializing trace_seq" * tag 'trace-v5.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: tracing: Initialize iter->seq after zeroing in tracing_read_pipe() tracing/hwlat: Don't ignore outer-loop duration when calculating max_latency tracing/hwlat: Report total time spent in all NMIs during the sample recordmcount: Fix nop_mcount() function tracing: Do not create tracefs files if tracefs lockdown is in effect tracing: Add locked_down checks to the open calls of files created for tracefs tracing: Add tracing_check_open_get_tr() tracing: Have trace events system open call tracing_open_generic_tr() tracing: Get trace_array reference for available_tracers files ftrace: Get a reference counter for the trace_array on filter files tracefs: Revert ccbd54ff54e8 ("tracefs: Restrict tracefs when the kernel is locked down")
| * | recordmcount: Fix nop_mcount() functionSteven Rostedt (VMware)2019-10-121-4/+1
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.home Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Tested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Fixes: 3f1df12019f3 ("recordmcount: Rewrite error/success handling") Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
* | Merge tag 'modules-for-v5.4-rc3' of ↵Linus Torvalds2019-10-113-16/+19
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux Pull module fixes from Jessica Yu: "Code cleanups and kbuild/namespace related fixups from Masahiro. Most importantly, it fixes a namespace-related modpost issue for external module builds - Fix broken external module builds due to a modpost bug in read_dump(), where the namespace was not being strdup'd and sym->namespace would be set to bogus data. - Various namespace-related kbuild fixes and cleanups thanks to Masahiro Yamada" * tag 'modules-for-v5.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux: doc: move namespaces.rst from kbuild/ to core-api/ nsdeps: make generated patches independent of locale nsdeps: fix hashbang of scripts/nsdeps kbuild: fix build error of 'make nsdeps' in clean tree module: rename __kstrtab_ns_* to __kstrtabns_* to avoid symbol conflict modpost: fix broken sym->namespace for external module builds module: swap the order of symbol.namespace scripts: add_namespace: Fix coccicheck failed
| * nsdeps: make generated patches independent of localeMasahiro Yamada2019-10-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 f55f2328bb28 ("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: Matthias Maennich <maennich@google.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Jessica Yu <jeyu@kernel.org>
| * nsdeps: fix hashbang of scripts/nsdepsMasahiro Yamada2019-10-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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: Matthias Maennich <maennich@google.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Jessica Yu <jeyu@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-13 10:19:16 +0000