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

scripts/kallsyms: fix definitely-lost memory leak

2020-01-04T12:59:51+00:00

[ 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 Signed-off-by: Sasha Levin

modpost: skip ELF local symbols during section mismatch check

2019-12-17T19:38:30+00:00

[ Upstream commit a4d26f1a0958bb1c2b60c6f1e67c6f5d43e2647b ] During development of a serial console driver with a gcc 8.2.0 toolchain for RISC-V, the following modpost warning appeared: ---- WARNING: vmlinux.o(.data+0x19b10): Section mismatch in reference from the variable .LANCHOR1 to the function .init.text:sifive_serial_console_setup() The variable .LANCHOR1 references the function __init sifive_serial_console_setup() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console ---- ".LANCHOR1" is an ELF local symbol, automatically created by gcc's section anchor generation code: https://gcc.gnu.org/onlinedocs/gccint/Anchored-Addresses.html https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/varasm.c;h=cd9591a45617464946dcf9a126dde277d9de9804;hb=9fb89fa845c1b2e0a18d85ada0b077c84508ab78#l7473 This was verified by compiling the kernel with -fno-section-anchors and observing that the ".LANCHOR1" ELF local symbol disappeared, and modpost no longer warned about the section mismatch. The serial driver code idiom triggering the warning is standard Linux serial driver practice that has a specific whitelist inclusion in modpost.c. I'm neither a modpost nor an ELF expert, but naively, it doesn't seem useful for modpost to report section mismatch warnings caused by ELF local symbols by default. Local symbols have compiler-generated names, and thus bypass modpost's whitelisting algorithm, which relies on the presence of a non-autogenerated symbol name. This increases the likelihood that false positive warnings will be generated (as in the above case). Thus, disable section mismatch reporting on ELF local symbols. The rationale here is similar to that of commit 2e3a10a1551d ("ARM: avoid ARM binutils leaking ELF local symbols") and of similar code already present in modpost.c: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/mod/modpost.c?h=v4.19-rc4&id=7876320f88802b22d4e2daf7eb027dd14175a0f8#n1256 This third version of the patch implements a suggestion from Masahiro Yamada to restructure the code as an additional pattern matching step inside secref_whitelist(), and further improves the patch description. Signed-off-by: Paul Walmsley Signed-off-by: Paul Walmsley Acked-by: Sam Ravnborg Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

scripts/gdb: fix debugging modules compiled with hot/cold partitioning

2019-12-05T14:37:04+00:00

[ Upstream commit 8731acc5068eb3f422a45c760d32198175c756f8 ] 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 Reviewed-by: Jan Kiszka Cc: Kieran Bingham Cc: Heiko Carstens Cc: Vasily Gorbik Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin

scripts/setlocalversion: Improve -dirty check with git-status --no-optional-locks

2019-11-06T11:42:55+00:00

[ Upstream commit ff64dd4857303dd5550faed9fd598ac90f0f2238 ] git-diff-index does not refresh the index for you, so using it for a "-dirty" check can give misleading results. Commit 6147b1cf19651 ("scripts/setlocalversion: git: Make -dirty check more robust") tried to fix this by switching to git-status, but it overlooked the fact that git-status also writes to the .git directory of the source tree, which is definitely not kosher for an out-of-tree (O=) build. That is getting reverted. Fortunately, git-status now supports avoiding writing to the index via the --no-optional-locks flag, as of git 2.14. It still calculates an up-to-date index, but it avoids writing it out to the .git directory. So, let's retry the solution from commit 6147b1cf19651 using this new flag first, and if it fails, we assume this is an older version of git and just use the old git-diff-index method. It's hairy to get the 'grep -vq' (inverted matching) correct by stashing the output of git-status (you have to be careful about the difference betwen "empty stdin" and "blank line on stdin"), so just pipe the output directly to grep and use a regex that's good enough for both the git-status and git-diff-index version. Cc: Christian Kujau Cc: Guenter Roeck Suggested-by: Alexander Kapshuk Signed-off-by: Brian Norris Tested-by: Genki Sky Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

namespace: fix namespace.pl script to support relative paths

2019-10-29T08:16:59+00:00

[ Upstream commit 82fdd12b95727640c9a8233c09d602e4518e71f7 ] 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 7e1c04779efd ("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: Jacob Keller Acked-by: Randy Dunlap Tested-by: Randy Dunlap Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

randstruct: Check member structs in is_pure_ops_struct()

2019-10-05T10:48:05+00:00

commit 60f2c82ed20bde57c362e66f796cf9e0e38a6dbb upstream. While no uses in the kernel triggered this case, it was possible to have a false negative where a struct contains other structs which contain only function pointers because of unreachable code in is_pure_ops_struct(). Signed-off-by: Joonwon Kang Link: https://lore.kernel.org/r/20190727155841.GA13586@host Fixes: 313dd1b62921 ("gcc-plugins: Add the randstruct plugin") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman

scripts/decode_stacktrace: match basepath using shell prefix operator, not regex

2019-09-16T06:20:46+00:00

[ Upstream commit 31013836a71e07751a6827f9d2ad41ef502ddaff ] The basepath may contain special characters, which would confuse the regex matcher. ${var#prefix} does the right thing. Link: http://lkml.kernel.org/r/20190518055946.181563-1-drinkcat@chromium.org Fixes: 67a28de47faa8358 ("scripts/decode_stacktrace: only strip base path when a prefix of the path") Signed-off-by: Nicolas Boichat Reviewed-by: Stephen Boyd Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin

kbuild: modpost: handle KBUILD_EXTRA_SYMBOLS only for external modules

2019-08-25T08:50:14+00:00

[ Upstream commit cb4819934a7f9b87876f11ed05b8624c0114551b ] KBUILD_EXTRA_SYMBOLS makes sense only when building external modules. Moreover, the modpost sets 'external_module' if the -e option is given. I replaced $(patsubst %, -e %,...) with simpler $(addprefix -e,...) while I was here. Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

scripts/sphinx-pre-install: fix script for RHEL/CentOS

2019-08-16T08:13:51+00:00

[ Upstream commit b308467c916aa7acc5069802ab76a9f657434701 ] There's a missing parenthesis at the script, with causes it to fail to detect non-Fedora releases (e. g. RHEL/CentOS). Tested with Centos 7.6.1810. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

kallsyms: exclude kasan local symbols on s390

2019-07-31T05:28:54+00:00

[ Upstream commit 33177f01ca3fe550146bb9001bec2fd806b2f40c ] gcc asan instrumentation emits the following sequence to store frame pc when the kernel is built with CONFIG_RELOCATABLE: debug/vsprintf.s: .section .data.rel.ro.local,"aw" .align 8 .LC3: .quad .LASANPC4826@GOTOFF .text .align 8 .type number, @function number: .LASANPC4826: and in case reloc is issued for LASANPC label it also gets into .symtab with the same address as actual function symbol: $ nm -n vmlinux | grep 0000000001397150 0000000001397150 t .LASANPC4826 0000000001397150 t number In the end kernel backtraces are almost unreadable: [ 143.748476] Call Trace: [ 143.748484] ([<000000002da3e62c>] .LASANPC2671+0x114/0x190) [ 143.748492] [<000000002eca1a58>] .LASANPC2612+0x110/0x160 [ 143.748502] [<000000002de9d830>] print_address_description+0x80/0x3b0 [ 143.748511] [<000000002de9dd64>] __kasan_report+0x15c/0x1c8 [ 143.748521] [<000000002ecb56d4>] strrchr+0x34/0x60 [ 143.748534] [<000003ff800a9a40>] kasan_strings+0xb0/0x148 [test_kasan] [ 143.748547] [<000003ff800a9bba>] kmalloc_tests_init+0xe2/0x528 [test_kasan] [ 143.748555] [<000000002da2117c>] .LASANPC4069+0x354/0x748 [ 143.748563] [<000000002dbfbb16>] do_init_module+0x136/0x3b0 [ 143.748571] [<000000002dbff3f4>] .LASANPC3191+0x2164/0x25d0 [ 143.748580] [<000000002dbffc4c>] .LASANPC3196+0x184/0x1b8 [ 143.748587] [<000000002ecdf2ec>] system_call+0xd8/0x2d8 Since LASANPC labels are not even unique and get into .symtab only due to relocs filter them out in kallsyms. Signed-off-by: Vasily Gorbik Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin