kernel/linux.git/scripts, branch v4.9.160

scripts/decode_stacktrace: only strip base path when a prefix of the path

2019-02-12T18:44:58+00:00

[ Upstream commit 67a28de47faa83585dd644bd4c31e5a1d9346c50 ] Running something like: decodecode vmlinux . leads to interested results where not only the leading "." gets stripped from the displayed paths, but also anywhere in the string, displaying something like: kvm_vcpu_check_block (arch/arm64/kvm/virt/kvm/kvm_mainc:2141) which doesn't help further processing. Fix it by only stripping the base path if it is a prefix of the path. Link: http://lkml.kernel.org/r/20181210174659.31054-3-marc.zyngier@arm.com Signed-off-by: Marc Zyngier Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin

modpost: validate symbol names also in find_elf_symbol

2019-02-12T18:44:52+00:00

[ Upstream commit 5818c683a619c534c113e1f66d24f636defc29bc ] If an ARM mapping symbol shares an address with a valid symbol, find_elf_symbol can currently return the mapping symbol instead, as the symbol is not validated. This can result in confusing warnings: WARNING: vmlinux.o(.text+0x18f4028): Section mismatch in reference from the function set_reset_devices() to the variable .init.text:$x.0 This change adds a call to is_valid_name to find_elf_symbol, similarly to how it's already used in find_elf_symbol2. Signed-off-by: Sami Tolvanen Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

kconfig: fix memory leak when EOF is encountered in quotation

2019-01-26T08:38:34+00:00

[ Upstream commit fbac5977d81cb2b2b7e37b11c459055d9585273c ] An unterminated string literal followed by new line is passed to the parser (with "multi-line strings not supported" warning shown), then handled properly there. On the other hand, an unterminated string literal at end of file is never passed to the parser, then results in memory leak. [Test Code] ----------(Kconfig begin)---------- source "Kconfig.inc" config A bool "a" -----------(Kconfig end)----------- --------(Kconfig.inc begin)-------- config B bool "b\No new line at end of file ---------(Kconfig.inc end)--------- [Summary from Valgrind] Before the fix: LEAK SUMMARY: definitely lost: 16 bytes in 1 blocks ... After the fix: LEAK SUMMARY: definitely lost: 0 bytes in 0 blocks ... Eliminate the memory leak path by handling this case. Of course, such a Kconfig file is wrong already, so I will add an error message later. Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

kconfig: fix file name and line number of warn_ignored_character()

2019-01-26T08:38:34+00:00

[ Upstream commit 77c1c0fa8b1477c5799bdad65026ea5ff676da44 ] Currently, warn_ignore_character() displays invalid file name and line number. The lexer should use current_file->name and yylineno, while the parser should use zconf_curname() and zconf_lineno(). This difference comes from that the lexer is always going ahead of the parser. The parser needs to look ahead one token to make a shift/reduce decision, so the lexer is requested to scan more text from the input file. This commit fixes the warning message from warn_ignored_character(). [Test Code] ----(Kconfig begin)---- / -----(Kconfig end)----- [Output] Before the fix: :0:warning: ignoring unsupported character '/' After the fix: Kconfig:1:warning: ignoring unsupported character '/' Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

checkstack.pl: fix for aarch64

2019-01-13T09:03:48+00:00

[ Upstream commit f1733a1d3cd32a9492f4cf866be37bb46e10163d ] There is actually a space after "sp," like this, ffff2000080813c8: a9bb7bfd stp x29, x30, [sp, #-80]! Right now, checkstack.pl isn't able to print anything on aarch64, because it won't be able to match the stating objdump line of a function due to this missing space. Hence, it displays every stack as zero-size. After this patch, checkpatch.pl is able to match the start of a function's objdump, and is then able to calculate each function's stack correctly. Link: http://lkml.kernel.org/r/20181207195843.38528-1-cai@lca.pw Signed-off-by: Qian Cai Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin

kbuild: fix linker feature test macros when cross compiling with Clang

2018-12-13T08:20:30+00:00

(commit 86a9df597cdd564d2d29c65897bcad42519e3678 upstream) I was not seeing my linker flags getting added when using ld-option when cross compiling with Clang. Upon investigation, this seems to be due to a difference in how GCC vs Clang handle cross compilation. GCC is configured at build time to support one backend, that is implicit when compiling. Clang is explicit via the use of `-target ` and ships with all supported backends by default. GNU Make feature test macros that compile then link will always fail when cross compiling with Clang unless Clang's triple is passed along to the compiler. For example: $ clang -x c /dev/null -c -o temp.o $ aarch64-linux-android/bin/ld -E temp.o aarch64-linux-android/bin/ld: unknown architecture of input file `temp.o' is incompatible with aarch64 output aarch64-linux-android/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000400078 $ echo $? 1 $ clang -target aarch64-linux-android- -x c /dev/null -c -o temp.o $ aarch64-linux-android/bin/ld -E temp.o aarch64-linux-android/bin/ld: warning: cannot find entry symbol _start; defaulting to 00000000004002e4 $ echo $? 0 This causes conditional checks that invoke $(CC) without the target triple, then $(LD) on the result, to always fail. Suggested-by: Masahiro Yamada Signed-off-by: Nick Desaulniers Reviewed-by: Matthias Kaehlcke Signed-off-by: Masahiro Yamada [ND: readjusted for context] Signed-off-by: Greg Kroah-Hartman

unifdef: use memcpy instead of strncpy

2018-12-08T12:05:05+00:00

commit 38c7b224ce22c25fed04007839edf974bd13439d upstream. New versions of gcc reasonably warn about the odd pattern of strncpy(p, q, strlen(q)); which really doesn't make sense: the strncpy() ends up being just a slow and odd way to write memcpy() in this case. There was a comment about _why_ the code used strncpy - to avoid the terminating NUL byte, but memcpy does the same and avoids the warning. Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

Kbuild: suppress packed-not-aligned warning for default setting only

2018-12-08T12:05:04+00:00

commit 321cb0308a9e76841394b4bbab6a1107cfedbae0 upstream. gcc-8 reports many -Wpacked-not-aligned warnings. The below are some examples. ./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct ceph_entity_addr' is less than 8 [-Wpacked-not-aligned] } __attribute__ ((packed)); ./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct ceph_entity_addr' is less than 8 [-Wpacked-not-aligned] } __attribute__ ((packed)); ./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct ceph_entity_addr' is less than 8 [-Wpacked-not-aligned] } __attribute__ ((packed)); This patch suppresses this kind of warnings for default setting. Signed-off-by: Xiongfeng Wang Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman

kbuild: Add __cc-option macro

2018-11-23T07:20:35+00:00

commit 9f3f1fd299768782465cb32cdf0dd4528d11f26b upstream. cc-option uses KBUILD_CFLAGS and KBUILD_CPPFLAGS when it determines whether an option is supported or not. This is fine for options used to build the kernel itself, however some components like the x86 boot code use a different set of flags. Add the new macro __cc-option which is a more generic version of cc-option with additional parameters. One parameter is the compiler with which the check should be performed, the other the compiler options to be used instead KBUILD_C*FLAGS. Refactor cc-option and hostcc-option to use __cc-option and move hostcc-option to scripts/Kbuild.include. Suggested-by: Arnd Bergmann Suggested-by: Masahiro Yamada Signed-off-by: Matthias Kaehlcke Acked-by: Arnd Bergmann Acked-by: Michal Marek Signed-off-by: Masahiro Yamada Signed-off-by: Nick Desaulniers Signed-off-by: Greg Kroah-Hartman

kbuild: Add support to generate LLVM assembly files

2018-11-23T07:20:35+00:00

commit 433db3e260bc8134d4a46ddf20b3668937e12556 upstream. Add rules to kbuild in order to generate LLVM assembly files with the .ll extension when using clang. # from c code make CC=clang kernel/pid.ll Signed-off-by: Vinícius Tinti Signed-off-by: Behan Webster Signed-off-by: Matthias Kaehlcke Signed-off-by: Masahiro Yamada Signed-off-by: Nick Desaulniers Signed-off-by: Greg Kroah-Hartman