user/sven/linux.git/scripts, branch v6.0-rc2

asm goto: eradicate CC_HAS_ASM_GOTO

2022-08-21T17:06:28Z

GCC has supported asm goto since 4.5, and Clang has since version 9.0.0. The minimum supported versions of these tools for the build according to Documentation/process/changes.rst are 5.1 and 11.0.0 respectively. Remove the feature detection script, Kconfig option, and clean up some fallback code that is no longer supported. The removed script was also testing for a GCC specific bug that was fixed in the 4.7 release. Also remove workarounds for bpftrace using clang older than 9.0.0, since other BPF backend fixes are required at this point. Link: https://lore.kernel.org/lkml/CAK7LNATSr=BXKfkdW8f-H5VT_w=xBpT2ZQcZ7rm6JfkdE+QnmA@mail.gmail.com/ Link: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48637 Acked-by: Borislav Petkov Suggested-by: Masahiro Yamada Suggested-by: Alexei Starovoitov Signed-off-by: Nick Desaulniers Reviewed-by: Ingo Molnar Reviewed-by: Nathan Chancellor Reviewed-by: Alexandre Belloni Signed-off-by: Linus Torvalds

Merge tag 'kbuild-fixes-v6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild

2022-08-20T21:55:38Z

Pull Kbuild fixes from Masahiro Yamada: - Fix module versioning broken on some architectures - Make dummy-tools enable CONFIG_PPC_LONG_DOUBLE_128 - Remove -Wformat-zero-length, which has no warning instance - Fix the order between drivers and libs in modules.order - Fix false-positive warnings in clang-analyzer * tag 'kbuild-fixes-v6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: scripts/clang-tools: Remove DeprecatedOrUnsafeBufferHandling check kbuild: fix the modules order between drivers and libs scripts/Makefile.extrawarn: Do not disable clang's -Wformat-zero-length kbuild: dummy-tools: pretend we understand __LONG_DOUBLE_128__ modpost: fix module versioning when a symbol lacks valid CRC

scripts/clang-tools: Remove DeprecatedOrUnsafeBufferHandling check

2022-08-20T17:47:49Z

This `clang-analyzer` check flags the use of memset(), suggesting a more secure version of the API, such as memset_s(), which does not exist in the kernel: warning: Call to function 'memset' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'memset_s' in case of C11 [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling] Signed-off-by: Guru Das Srinagesh Reviewed-by: Nick Desaulniers Signed-off-by: Masahiro Yamada

scripts/Makefile.extrawarn: Do not disable clang's -Wformat-zero-length

2022-08-20T17:47:48Z

There are no instances of this warning in the tree across several difference architectures and configurations. This was added by commit 26ea6bb1fef0 ("kbuild, LLVMLinux: Supress warnings unless W=1-3") back in 2014, where it might have been necessary, but there are no instances of it now so stop disabling it to increase warning coverage for clang. Signed-off-by: Nathan Chancellor Signed-off-by: Masahiro Yamada

kbuild: dummy-tools: pretend we understand __LONG_DOUBLE_128__

2022-08-20T17:47:48Z

There is a test in powerpc's Kconfig which checks __LONG_DOUBLE_128__ and sets CONFIG_PPC_LONG_DOUBLE_128 if it is understood by the compiler. We currently don't handle it, so this results in PPC_LONG_DOUBLE_128 not being in super-config generated by dummy-tools. So take this into account in the gcc script and preprocess __LONG_DOUBLE_128__ as "1". Signed-off-by: Jiri Slaby Signed-off-by: Masahiro Yamada

modpost: fix module versioning when a symbol lacks valid CRC

2022-08-20T17:47:36Z

Since commit 7b4537199a4a ("kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS"), module versioning is broken on some architectures. Loading a module fails with "disagrees about version of symbol module_layout". On such architectures (e.g. ARCH=sparc build with sparc64_defconfig), modpost shows a warning, like follows: WARNING: modpost: EXPORT symbol "_mcount" [vmlinux] version generation failed, symbol will not be versioned. Is "_mcount" prototyped in ? Previously, it was a harmless warning (CRC check was just skipped), but now wrong CRCs are used for comparison because invalid CRCs are just skipped. $ sparc64-linux-gnu-nm -n vmlinux [snip] 0000000000c2cea0 r __ksymtab__kstrtol 0000000000c2ceb8 r __ksymtab__kstrtoul 0000000000c2ced0 r __ksymtab__local_bh_enable 0000000000c2cee8 r __ksymtab__mcount 0000000000c2cf00 r __ksymtab__printk 0000000000c2cf18 r __ksymtab__raw_read_lock 0000000000c2cf30 r __ksymtab__raw_read_lock_bh [snip] 0000000000c53b34 D __crc__kstrtol 0000000000c53b38 D __crc__kstrtoul 0000000000c53b3c D __crc__local_bh_enable 0000000000c53b40 D __crc__printk 0000000000c53b44 D __crc__raw_read_lock 0000000000c53b48 D __crc__raw_read_lock_bh Please notice __crc__mcount is missing here. When the module subsystem looks up a CRC that comes after, it results in reading out a wrong address. For example, when __crc__printk is needed, the module subsystem reads 0xc53b44 instead of 0xc53b40. All CRC entries must be output for correct index accessing. Invalid CRCs will be unused, but are needed to keep the one-to-one mapping between __ksymtab_* and __crc_*. The best is to fix all modpost warnings, but several warnings are still remaining on less popular architectures. Fixes: 7b4537199a4a ("kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS") Reported-by: matoro Signed-off-by: Masahiro Yamada Tested-by: matoro

Merge tag 'hardening-v6.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2022-08-19T20:56:14Z

Pull hardening fixes from Kees Cook: - Also undef LATENT_ENTROPY_PLUGIN for per-file disabling (Andrew Donnellan) - Return EFAULT on copy_from_user() failures in LoadPin (Kees Cook) * tag 'hardening-v6.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: gcc-plugins: Undefine LATENT_ENTROPY_PLUGIN when plugin disabled for a file LoadPin: Return EFAULT on copy_from_user() failures

gcc-plugins: Undefine LATENT_ENTROPY_PLUGIN when plugin disabled for a file

2022-08-16T19:25:53Z

Commit 36d4b36b6959 ("lib/nodemask: inline next_node_in() and node_random()") refactored some code by moving node_random() from lib/nodemask.c to include/linux/nodemask.h, thus requiring nodemask.h to include random.h, which conditionally defines add_latent_entropy() depending on whether the macro LATENT_ENTROPY_PLUGIN is defined. This broke the build on powerpc, where nodemask.h is indirectly included in arch/powerpc/kernel/prom_init.c, part of the early boot machinery that is excluded from the latent entropy plugin using DISABLE_LATENT_ENTROPY_PLUGIN. It turns out that while we add a gcc flag to disable the actual plugin, we don't undefine LATENT_ENTROPY_PLUGIN. This leads to the following: CC arch/powerpc/kernel/prom_init.o In file included from ./include/linux/nodemask.h:97, from ./include/linux/mmzone.h:17, from ./include/linux/gfp.h:7, from ./include/linux/xarray.h:15, from ./include/linux/radix-tree.h:21, from ./include/linux/idr.h:15, from ./include/linux/kernfs.h:12, from ./include/linux/sysfs.h:16, from ./include/linux/kobject.h:20, from ./include/linux/pci.h:35, from arch/powerpc/kernel/prom_init.c:24: ./include/linux/random.h: In function 'add_latent_entropy': ./include/linux/random.h:25:46: error: 'latent_entropy' undeclared (first use in this function); did you mean 'add_latent_entropy'? 25 | add_device_randomness((const void *)&latent_entropy, sizeof(latent_entropy)); | ^~~~~~~~~~~~~~ | add_latent_entropy ./include/linux/random.h:25:46: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [scripts/Makefile.build:249: arch/powerpc/kernel/prom_init.o] Fehler 1 make[1]: *** [scripts/Makefile.build:465: arch/powerpc/kernel] Fehler 2 make: *** [Makefile:1855: arch/powerpc] Error 2 Change the DISABLE_LATENT_ENTROPY_PLUGIN flags to undefine LATENT_ENTROPY_PLUGIN for files where the plugin is disabled. Cc: Yury Norov Fixes: 38addce8b600 ("gcc-plugins: Add latent_entropy plugin") Link: https://bugzilla.kernel.org/show_bug.cgi?id=216367 Link: https://lore.kernel.org/linuxppc-dev/alpine.DEB.2.22.394.2208152006320.289321@ramsan.of.borg/ Reported-by: Erhard Furtner Signed-off-by: Andrew Donnellan Reviewed-by: Yury Norov Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220816051720.44108-1-ajd@linux.ibm.com

Merge tag 'riscv-for-linus-5.20-mw2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux

2022-08-13T01:39:43Z

Pull more RISC-V updates from Palmer Dabbelt: "There's still a handful of new features in here, but there are a lot of fixes/cleanups as well: - Support for the Zicbom extension for explicit cache-block management, along with the necessary bits to make the non-standard cache management ops on the Allwinner D1 function - Support for the Zihintpause extension, which codifies a go-slow instruction used for cpu_relax() - Support for the Sstc extension for supervisor-mode timer/counter management - Many device tree fixes and cleanups, including a large set for the Canaan device trees - A handful of fixes and cleanups for the PMU driver" * tag 'riscv-for-linus-5.20-mw2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: (43 commits) dt-bindings: gpio: sifive: add gpio-line-names wireguard: selftests: set CONFIG_NONPORTABLE on riscv32 RISC-V: KVM: Support sstc extension RISC-V: Improve SBI definitions RISC-V: Move counter info definition to sbi header file RISC-V: Fix SBI PMU calls for RV32 RISC-V: Update user page mapping only once during start RISC-V: Fix counter restart during overflow for RV32 RISC-V: Prefer sstc extension if available RISC-V: Enable sstc extension parsing from DT RISC-V: Add SSTC extension CSR details riscv:uprobe fix SR_SPIE set/clear handling dt-bindings: riscv: fix SiFive l2-cache's cache-sets riscv: ensure cpu_ops_sbi is declared RISC-V: cpu_ops_spinwait.c should include head.h RISC-V: Declare cpu_ops_spinwait in riscv: dts: starfive: correct number of external interrupts riscv: dts: sifive unmatched: Add PWM controlled LEDs riscv/purgatory: Omit use of bin2c riscv/purgatory: hard-code obj-y in Makefile ...

riscv/purgatory: Omit use of bin2c

2022-08-11T16:32:34Z

The .incbin assembler directive is much faster than bin2c + $(CC). Do similar refactoring as in commit 4c0f032d4963 ("s390/purgatory: Omit use of bin2c"). Please note the .quad directive matches to size_t in C (both 8 byte) because the purgatory is compiled only for the 64-bit kernel. (KEXEC_FILE depends on 64BIT). Signed-off-by: Masahiro Yamada Link: https://lore.kernel.org/r/20220625223438.835408-2-masahiroy@kernel.org Signed-off-by: Palmer Dabbelt