user/sven/linux.git/scripts, branch v4.4.146

Kbuild: fix # escaping in .cmd files for future Make

2018-07-19T13:35:57Z

commit 9564a8cf422d7b58f6e857e3546d346fa970191e upstream. I tried building using a freshly built Make (4.2.1-69-g8a731d1), but already the objtool build broke with orc_dump.c: In function ‘orc_dump’: orc_dump.c:106:2: error: ‘elf_getshnum’ is deprecated [-Werror=deprecated-declarations] if (elf_getshdrnum(elf, &nr_sections)) { Turns out that with that new Make, the backslash was not removed, so cpp didn't see a #include directive, grep found nothing, and -DLIBELF_USE_DEPRECATED was wrongly put in CFLAGS. Now, that new Make behaviour is documented in their NEWS file: * WARNING: Backward-incompatibility! Number signs (#) appearing inside a macro reference or function invocation no longer introduce comments and should not be escaped with backslashes: thus a call such as: foo := $(shell echo '#') is legal. Previously the number sign needed to be escaped, for example: foo := $(shell echo '\#') Now this latter will resolve to "\#". If you want to write makefiles portable to both versions, assign the number sign to a variable: C := \# foo := $(shell echo '$C') This was claimed to be fixed in 3.81, but wasn't, for some reason. To detect this change search for 'nocomment' in the .FEATURES variable. This also fixes up the two make-cmd instances to replace # with $(pound) rather than with \#. There might very well be other places that need similar fixup in preparation for whatever future Make release contains the above change, but at least this builds an x86_64 defconfig with the new make. Link: https://bugzilla.kernel.org/show_bug.cgi?id=197847 Cc: Randy Dunlap Signed-off-by: Rasmus Villemoes Signed-off-by: Masahiro Yamada Cc: Konstantin Khlebnikov Signed-off-by: Greg Kroah-Hartman

kconfig: Avoid format overflow warning from GCC 8.1

2018-06-13T14:15:27Z

commit 2ae89c7a82ea9d81a19b4fc2df23bef4b112f24e upstream. In file included from scripts/kconfig/zconf.tab.c:2485: scripts/kconfig/confdata.c: In function ‘conf_write’: scripts/kconfig/confdata.c:773:22: warning: ‘%s’ directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=] sprintf(newname, "%s%s", dirname, basename); ^~ scripts/kconfig/confdata.c:773:19: note: assuming directive output of 7 bytes sprintf(newname, "%s%s", dirname, basename); ^~~~~~ scripts/kconfig/confdata.c:773:2: note: ‘sprintf’ output 1 or more bytes (assuming 4104) into a destination of size 4097 sprintf(newname, "%s%s", dirname, basename); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ scripts/kconfig/confdata.c:776:23: warning: ‘.tmpconfig.’ directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=] sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid()); ^~~~~~~~~~~ scripts/kconfig/confdata.c:776:3: note: ‘sprintf’ output between 13 and 4119 bytes into a destination of size 4097 sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid()); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Increase the size of tmpname and newname to make GCC happy. Signed-off-by: Nathan Chancellor Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman

kconfig: Fix expr_free() E_NOT leak

2018-05-30T05:48:53Z

[ Upstream commit 5b1374b3b3c2fc4f63a398adfa446fb8eff791a4 ] Only the E_NOT operand and not the E_NOT node itself was freed, due to accidentally returning too early in expr_free(). Outline of leak: switch (e->type) { ... case E_NOT: expr_free(e->left.expr); return; ... } *Never reached, 'e' leaked* free(e); Fix by changing the 'return' to a 'break'. Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix: LEAK SUMMARY: definitely lost: 44,448 bytes in 1,852 blocks ... Summary after the fix: LEAK SUMMARY: definitely lost: 1,608 bytes in 67 blocks ... Signed-off-by: Ulf Magnusson Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

kconfig: Fix automatic menu creation mem leak

2018-05-30T05:48:53Z

[ Upstream commit ae7440ef0c8013d68c00dad6900e7cce5311bb1c ] expr_trans_compare() always allocates and returns a new expression, giving the following leak outline: ... *Allocate* basedep = expr_trans_compare(basedep, E_UNEQUAL, &symbol_no); ... for (menu = parent->next; menu; menu = menu->next) { ... *Copy* dep2 = expr_copy(basedep); ... *Free copy* expr_free(dep2); } *basedep lost!* Fix by freeing 'basedep' after the loop. Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix: LEAK SUMMARY: definitely lost: 344,376 bytes in 14,349 blocks ... Summary after the fix: LEAK SUMMARY: definitely lost: 44,448 bytes in 1,852 blocks ... Signed-off-by: Ulf Magnusson Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

kconfig: Don't leak main menus during parsing

2018-05-30T05:48:53Z

[ Upstream commit 0724a7c32a54e3e50d28e19e30c59014f61d4e2c ] If a 'mainmenu' entry appeared in the Kconfig files, two things would leak: - The 'struct property' allocated for the default "Linux Kernel Configuration" prompt. - The string for the T_WORD/T_WORD_QUOTE prompt after the T_MAINMENU token, allocated on the heap in zconf.l. To fix it, introduce a new 'no_mainmenu_stmt' nonterminal that matches if there's no 'mainmenu' and adds the default prompt. That means the prompt only gets allocated once regardless of whether there's a 'mainmenu' statement or not, and managing it becomes simple. Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix: LEAK SUMMARY: definitely lost: 344,568 bytes in 14,352 blocks ... Summary after the fix: LEAK SUMMARY: definitely lost: 344,440 bytes in 14,350 blocks ... Signed-off-by: Ulf Magnusson Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

tags: honor COMPILED_SOURCE with apart output directory

2018-04-13T17:50:18Z

[ Upstream commit cbf52a3e6a8a92beec6e0c70abf4111cd8f8faf7 ] When the kernel is compiled with an "O=" argument, the object files are not in the source tree, but in the build tree. This patch fixes O= build by looking for object files in the build tree. Fixes: 923e02ecf3f8 ("scripts/tags.sh: Support compiled source") Signed-off-by: Robert Jarzmik Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

kbuild: Handle builtin dtb file names containing hyphens

2018-03-18T10:17:49Z

commit 55fe6da9efba102866e2fb5b40b04b6a4b26c19e upstream. cmd_dt_S_dtb constructs the assembly source to incorporate a devicetree FDT (that is, the .dtb file) as binary data in the kernel image. This assembly source contains labels before and after the binary data. The label names incorporate the file name of the corresponding .dtb file. Hyphens are not legal characters in labels, so .dtb files built into the kernel with hyphens in the file name result in errors like the following: bcm3368-netgear-cvg834g.dtb.S: Assembler messages: bcm3368-netgear-cvg834g.dtb.S:5: Error: : no such section bcm3368-netgear-cvg834g.dtb.S:5: Error: junk at end of line, first unrecognized character is `-' bcm3368-netgear-cvg834g.dtb.S:6: Error: unrecognized opcode `__dtb_bcm3368-netgear-cvg834g_begin:' bcm3368-netgear-cvg834g.dtb.S:8: Error: unrecognized opcode `__dtb_bcm3368-netgear-cvg834g_end:' bcm3368-netgear-cvg834g.dtb.S:9: Error: : no such section bcm3368-netgear-cvg834g.dtb.S:9: Error: junk at end of line, first unrecognized character is `-' Fix this by updating cmd_dt_S_dtb to transform all hyphens from the file name to underscores when constructing the labels. As of v4.16-rc2, 1139 .dts files across ARM64, ARM, MIPS and PowerPC contain hyphens in their names, but the issue only currently manifests on Broadcom MIPS platforms, as that is the only place where such files are built into the kernel. For example when CONFIG_DT_NETGEAR_CVG834G=y, or on BMIPS kernels when the dtbs target is used (in the latter case it admittedly shouldn't really build all the dtb.o files, but thats a separate issue). Fixes: 695835511f96 ("MIPS: BMIPS: rename bcm96358nb4ser to bcm6358-neufbox4-sercom") Signed-off-by: James Hogan Reviewed-by: Frank Rowand Cc: Rob Herring Cc: Michal Marek Cc: Ralf Baechle Cc: Florian Fainelli Cc: Kevin Cernekee Cc: # 4.9+ Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman

module/retpoline: Warn about missing retpoline in module

2018-02-25T10:03:52Z

(cherry picked from commit caf7501a1b4ec964190f31f9c3f163de252273b8) There's a risk that a kernel which has full retpoline mitigations becomes vulnerable when a module gets loaded that hasn't been compiled with the right compiler or the right option. To enable detection of that mismatch at module load time, add a module info string "retpoline" at build time when the module was compiled with retpoline support. This only covers compiled C source, but assembler source or prebuilt object files are not checked. If a retpoline enabled kernel detects a non retpoline protected module at load time, print a warning and report it in the sysfs vulnerability file. [ tglx: Massaged changelog ] Signed-off-by: Andi Kleen Signed-off-by: Thomas Gleixner Cc: David Woodhouse Cc: gregkh@linuxfoundation.org Cc: torvalds@linux-foundation.org Cc: jeyu@kernel.org Cc: arjan@linux.intel.com Link: https://lkml.kernel.org/r/20180125235028.31211-1-andi@firstfloor.org Signed-off-by: David Woodhouse [jwang: port to 4.4] Signed-off-by: Jack Wang Signed-off-by: Greg Kroah-Hartman

genksyms: Fix segfault with invalid declarations

2018-02-25T10:03:51Z

commit d920f7c6628c63a390009c237fb80a203c2e400a upstream. Do not try to recover too early and segfault when parsing invalid declarations such as echo 'int (int);' | scripts/genksyms/genksyms echo 'int a, (int);' | scripts/genksyms/genksyms echo 'extern void *__inline_memcpy((void *), (const void *), (__kernel_size_t));' | scripts/genksyms/genksyms The last one was a real-life bug with include/asm-generic/asm-prototypes.h on x86_64. Reported-and-tested-by: Borislav Petkov Signed-off-by: Michal Marek [arnd: rebase to 4.4, regenerate parse.tab.{c,h}] Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman

scripts/kernel-doc: Don't fail with status != 0 if error encountered with -none

2018-02-25T10:03:39Z

[ Upstream commit e814bccbafece52a24e152d2395b5d49eef55841 ] My bisect scripts starting running into build failures when trying to compile 4.15-rc1 with the builds failing with things like: drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2078: error: Cannot parse struct or union! The line in question is actually just a #define, but after some digging it turns out that my scripts pass W=1 and since commit 3a025e1d1c2ea ("Add optional check for bad kernel-doc comments") that results in kernel-doc running on each source file. The file in question has a badly formatted comment immediately before the #define: /** * struct brcmf_skbuff_cb reserves first two bytes in sk_buff::cb for * bus layer usage. */ which causes the regex in dump_struct to fail (lack of braces following struct declaration) and kernel-doc returns 1, which causes the build to fail. Fix the issue by always returning 0 from kernel-doc when invoked with -none. It successfully generates no documentation, and prints out any issues. Cc: Matthew Wilcox Cc: Jonathan Corbet Signed-off-by: Will Deacon Signed-off-by: Jonathan Corbet Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman