aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-01-14kbuild: rename cmd_{bzip2,lzma,lzo,lz4,xzkern,zstd22}Masahiro Yamada
GZIP-compressed files end with 4 byte data that represents the size of the original input. The decompressors (the self-extracting kernel) exploit it to know the vmlinux size beforehand. To mimic the GZIP's trailer, Kbuild provides cmd_{bzip2,lzma,lzo,lz4,xzkern,zstd22}. Unfortunately these macros are used everywhere despite the appended size data is only useful for the decompressors. There is no guarantee that such hand-crafted trailers are safely ignored. In fact, the kernel refuses compressed initramdfs with the garbage data. That is why usr/Makefile overrides size_append to make it no-op. To limit the use of such broken compressed files, this commit renames the existing macros as follows: cmd_bzip2 --> cmd_bzip2_with_size cmd_lzma --> cmd_lzma_with_size cmd_lzo --> cmd_lzo_with_size cmd_lz4 --> cmd_lz4_with_size cmd_xzkern --> cmd_xzkern_with_size cmd_zstd22 --> cmd_zstd22_with_size To keep the decompressors working, I updated the following Makefiles accordingly: arch/arm/boot/compressed/Makefile arch/h8300/boot/compressed/Makefile arch/mips/boot/compressed/Makefile arch/parisc/boot/compressed/Makefile arch/s390/boot/compressed/Makefile arch/sh/boot/compressed/Makefile arch/x86/boot/compressed/Makefile I reused the current macro names for the normal usecases; they produce the compressed data in the proper format. I did not touch the following: arch/arc/boot/Makefile arch/arm64/boot/Makefile arch/csky/boot/Makefile arch/mips/boot/Makefile arch/riscv/boot/Makefile arch/sh/boot/Makefile kernel/Makefile This means those Makefiles will stop appending the size data. I dropped the 'override size_append' hack from usr/Makefile. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de>
2022-01-14kbuild: drop $(size_append) from cmd_zstdMasahiro Yamada
The appended file size is only used by the decompressors, which some architectures support. As the comment "zstd22 is used for kernel compression" says, cmd_zstd22 is used in arch/{mips,s390,x86}/boot/compressed/Makefile. On the other hand, there is no good reason to append the file size to cmd_zstd since it is used for other purposes. Actually cmd_zstd is only used in usr/Makefile, where the appended file size is rather harmful. The initramfs with its file size appended is considered as corrupted data, so commit 65e00e04e5ae ("initramfs: refactor the initramfs build rules") added 'override size_append := :' to make it no-op. As a conclusion, this $(size_append) should not exist here. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de>
2022-01-14sh: rename suffix-y to suffix_yMasahiro Yamada
'export suffix-y' does not work reliably because hyphens are disallowed in shell variables. A similar issue was fixed by commit 2bfbe7881ee0 ("kbuild: Do not use hyphen in exported variable name"). If I do similar in dash, ARCH=sh fails to build. $ mv linux linux~ $ cd linux~ $ dash $ make O=foo/bar ARCH=sh CROSS_COMPILE=sh4-linux-gnu- defconfig all make[1]: Entering directory '/home/masahiro/linux~/foo/bar' [ snip ] make[4]: *** No rule to make target 'arch/sh/boot/compressed/vmlinux.bin.', needed by 'arch/sh/boot/compressed/piggy.o'. Stop. make[3]: *** [/home/masahiro/linux~/arch/sh/boot/Makefile:40: arch/sh/boot/compressed/vmlinux] Error 2 make[2]: *** [/home/masahiro/linux~/arch/sh/Makefile:194: zImage] Error 2 make[1]: *** [/home/masahiro/linux~/Makefile:350: __build_one_by_one] Error 2 make[1]: Leaving directory '/home/masahiro/linux~/foo/bar' make: *** [Makefile:219: __sub-make] Error 2 The maintainer of GNU Make stated that there is no consistent way to export variables that do not meet the shell's naming criteria. (https://savannah.gnu.org/bugs/?55719) Consequently, you cannot use hyphens in exported variables. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de>
2022-01-08doc: kbuild: fix default in `imply` tableMiguel Ojeda
`BAZ` takes `FOO`'s value as default (as far as `BAR` allows it). Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-01-08microblaze: use built-in function to get CPU_{MAJOR,MINOR,REV}Masahiro Yamada
Use built-in functions instead of shell commands to avoid forking processes. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de>
2022-01-08certs: move scripts/extract-cert to certs/Masahiro Yamada
extract-cert is only used in certs/Makefile. Move it there and build extract-cert on demand. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-01-08kbuild: do not quote string values in include/config/auto.confMasahiro Yamada
The previous commit fixed up all shell scripts to not include include/config/auto.conf. Now that include/config/auto.conf is only included by Makefiles, we can change it into a more Make-friendly form. Previously, Kconfig output string values enclosed with double-quotes (both in the .config and include/config/auto.conf): CONFIG_X="foo bar" Unlike shell, Make handles double-quotes (and single-quotes as well) verbatim. We must rip them off when used. There are some patterns: [1] $(patsubst "%",%,$(CONFIG_X)) [2] $(CONFIG_X:"%"=%) [3] $(subst ",,$(CONFIG_X)) [4] $(shell echo $(CONFIG_X)) These are not only ugly, but also fragile. [1] and [2] do not work if the value contains spaces, like CONFIG_X=" foo bar " [3] does not work correctly if the value contains double-quotes like CONFIG_X="foo\"bar" [4] seems to work better, but has a cost of forking a process. Anyway, quoted strings were always PITA for our Makefiles. This commit changes Kconfig to stop quoting in include/config/auto.conf. These are the string type symbols referenced in Makefiles or scripts: ACPI_CUSTOM_DSDT_FILE ARC_BUILTIN_DTB_NAME ARC_TUNE_MCPU BUILTIN_DTB_SOURCE CC_IMPLICIT_FALLTHROUGH CC_VERSION_TEXT CFG80211_EXTRA_REGDB_KEYDIR EXTRA_FIRMWARE EXTRA_FIRMWARE_DIR EXTRA_TARGETS H8300_BUILTIN_DTB INITRAMFS_SOURCE LOCALVERSION MODULE_SIG_HASH MODULE_SIG_KEY NDS32_BUILTIN_DTB NIOS2_DTB_SOURCE OPENRISC_BUILTIN_DTB SOC_CANAAN_K210_DTB_SOURCE SYSTEM_BLACKLIST_HASH_LIST SYSTEM_REVOCATION_KEYS SYSTEM_TRUSTED_KEYS TARGET_CPU UNUSED_KSYMS_WHITELIST XILINX_MICROBLAZE0_FAMILY XILINX_MICROBLAZE0_HW_VER XTENSA_VARIANT_NAME I checked them one by one, and fixed up the code where necessary. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-01-08kbuild: do not include include/config/auto.conf from shell scriptsMasahiro Yamada
Richard Weinberger pointed out the risk of sourcing the kernel config from shell scripts [1], and proposed some patches [2], [3]. It is a good point, but it took a long time because I was wondering how to fix this. This commit goes with simple grep approach because there are only a few scripts including the kernel configuration. scripts/link_vmlinux.sh has references to a bunch of CONFIG options, all of which are boolean. I added is_enabled() helper as scripts/package/{mkdebian,builddeb} do. scripts/gen_autoksyms.sh uses 'eval', stating "to expand the whitelist path". I removed it since it is the issue we are trying to fix. I was a bit worried about the cost of invoking the grep command over again. I extracted the grep parts from it, and measured the cost. It was approximately 0.03 sec, which I hope is acceptable. [test code] $ cat test-grep.sh #!/bin/sh is_enabled() { grep -q "^$1=y" include/config/auto.conf } is_enabled CONFIG_LTO_CLANG is_enabled CONFIG_LTO_CLANG is_enabled CONFIG_STACK_VALIDATION is_enabled CONFIG_UNWINDER_ORC is_enabled CONFIG_FTRACE_MCOUNT_USE_OBJTOOL is_enabled CONFIG_VMLINUX_VALIDATION is_enabled CONFIG_FRAME_POINTER is_enabled CONFIG_GCOV_KERNEL is_enabled CONFIG_LTO_CLANG is_enabled CONFIG_RETPOLINE is_enabled CONFIG_X86_SMAP is_enabled CONFIG_LTO_CLANG is_enabled CONFIG_VMLINUX_MAP is_enabled CONFIG_KALLSYMS_ALL is_enabled CONFIG_KALLSYMS_ABSOLUTE_PERCPU is_enabled CONFIG_KALLSYMS_BASE_RELATIVE is_enabled CONFIG_DEBUG_INFO_BTF is_enabled CONFIG_KALLSYMS is_enabled CONFIG_DEBUG_INFO_BTF is_enabled CONFIG_BPF is_enabled CONFIG_BUILDTIME_TABLE_SORT is_enabled CONFIG_KALLSYMS $ time ./test-grep.sh real 0m0.036s user 0m0.027s sys m0.009s [1]: https://lore.kernel.org/all/1919455.eZKeABUfgV@blindfold/ [2]: https://lore.kernel.org/all/20180219092245.26404-1-richard@nod.at/ [3]: https://lore.kernel.org/all/20210920213957.1064-2-richard@nod.at/ Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de>
2022-01-08certs: simplify $(srctree)/ handling and remove config_filename macroMasahiro Yamada
The complex macro, config_filename, was introduced to do: [1] drop double-quotes from the string value [2] add $(srctree)/ prefix in case the file is not found in $(objtree) [3] escape spaces and more [1] will be more generally handled by Kconfig later. As for [2], Kbuild uses VPATH to search for files in $(objtree), $(srctree) in this order. GNU Make can natively handle it. As for [3], converting $(space) to $(space_escape) back and forth looks questionable to me. It is well-known that GNU Make cannot handle file paths with spaces in the first place. Instead of using the complex macro, use $< so it will be expanded to the file path of the key. Remove config_filename, finally. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-01-08kbuild: stop using config_filename in scripts/Makefile.modsignMasahiro Yamada
Toward the goal of removing the config_filename macro, drop the double-quotes and add $(srctree)/ prefix in an ad hoc way. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de>
2022-01-08certs: remove misleading comments about GCC PRMasahiro Yamada
This dependency is necessary irrespective of the mentioned GCC PR because the embedded certificates are build artifacts and must be generated by extract_certs before *.S files are compiled. The comment sounds like we are hoping to remove these dependencies someday. No, we cannot remove them. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-01-08certs: refactor file cleaningMasahiro Yamada
'make clean' removes files listed in 'targets'. It is redundant to specify both 'targets' and 'clean-files'. Move 'targets' assignments out of the ifeq-conditionals so scripts/Makefile.clean can see them. One effective change is that certs/certs/signing_key.x509 is now deleted by 'make clean' instead of 'make mrproper. This certificate is embedded in the kernel. It is not used in any way by external module builds. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de>
2022-01-08certs: remove unneeded -I$(srctree) option for system_certificates.oMasahiro Yamada
The .incbin directive in certs/system_certificates.S includes certs/signing_key.x509 and certs/x509_certificate_list, both of which are generated by extract_certs, i.e. exist in $(objtree). This option -I$(srctree) is unneeded. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-01-08certs: unify duplicated cmd_extract_certs and improve the logMasahiro Yamada
cmd_extract_certs is defined twice. Unify them. The current log shows the input file $(2), which might be empty. You cannot know what is being created from the log, "EXTRACT_CERTS". Change the log to show the output file with better alignment. [Before] EXTRACT_CERTS certs/signing_key.pem CC certs/system_keyring.o EXTRACT_CERTS AS certs/system_certificates.o CC certs/common.o CC certs/blacklist.o EXTRACT_CERTS AS certs/revocation_certificates.o [After] CERT certs/signing_key.x509 CC certs/system_keyring.o CERT certs/x509_certificate_list AS certs/system_certificates.o CC certs/common.o CC certs/blacklist.o CERT certs/x509_revocation_list AS certs/revocation_certificates.o Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de>
2022-01-08certs: use $< and $@ to simplify the key generation ruleMasahiro Yamada
Do not repeat $(obj)/x509.genkey or $(obj)/signing_key.pem Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de>
2022-01-08kbuild: remove headers_check stubMasahiro Yamada
Linux 5.15 is out. Remove this stub now. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-01-08kbuild: move headers_check.pl to usr/include/Masahiro Yamada
This script is only used by usr/include/Makefile. Make it local to the directory. Update the comment in include/uapi/linux/soundcard.h because 'make headers_check' is no longer functional. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-12-11certs: use if_changed to re-generate the key when the key type is changedMasahiro Yamada
If the key type of the existing signing key does not match to CONFIG_MODULE_SIG_KEY_TYPE_*, the Makefile removes it so that it is re-generated. Use if_changed so that the key is re-generated when the key type is changed (that is, the openssl command line is changed). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-12-11certs: use 'cmd' to hide openssl output in silent builds more simplyMasahiro Yamada
Commit 5d06ee20b662 ("modsign: hide openssl output in silent builds") silenced the key generation log from openssl in silent builds. Since commit 174a1dcc9642 ("kbuild: sink stdout from cmd for silent build"), the 'cmd' macro can handle it in a cleaner way. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-12-11certs: remove noisy messages while generating the signing keyMasahiro Yamada
When you run Kbuild with the parallel option -j, the messages from this rule and others are interleaved, like follows: ### CC arch/x86/mm/pat/set_memory.o ### Now generating an X.509 key pair to be used for signing modules. ### ### If this takes a long time, you might wish to run rngd in the ### background to keep the supply of entropy topped up. It CC arch/x86/events/intel/bts.o HDRTEST usr/include/linux/qnx4_fs.h CC arch/x86/events/zhaoxin/core.o ### needs to be run as root, and uses a hardware random ### number generator if one is available. AR init/built-in.a ### On modern machines, it does not take a long time to generate the key. Remove the ugly log messages. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-12-11certs: check-in the default x509 config fileMasahiro Yamada
When x509.genkey is created, it prints a log: Generating X.509 key generation config ..., which is not the ordinary Kbuild log style. Check-in the default config as certs/default_x509.genkey to make it readable, and copy it to certs/x509.genkey if it is not present. The log is shown in the Kbuild style. COPY certs/x509.genkey Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-12-11certs: remove meaningless $(error ...) in certs/MakefileMasahiro Yamada
CONFIG_MODULE_SIG_HASH is defined by init/Kconfig. This $(error ...) is never reachable. (If it is, you need to fix the bug.) Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-12-11nds32: remove unused BUILTIN_DTB from arch/nds32/MakefileMasahiro Yamada
This is not used or exported. BUILTIN_DTB is locally defined and used in arch/nds32/boot/dts/Makefile. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-12-11certs: move the 'depends on' to the choice of module signing keysMasahiro Yamada
When the condition "MODULE_SIG || (IMA_APPRAISE_MODSIG && MODULES)" is unmet, you cannot choose anything in the choice, but the choice menu is still displayed in the menuconfig etc. Move the 'depends on' to the choice to hide the meaningless menu. Also delete the redundant 'default'. In a choice, the first entry is the default. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-12-02init/Kconfig: Drop linker version check for LD_ORPHAN_WARNNathan Chancellor
The minimum supported version of LLVM has been raised to 11.0.0, meaning this check is always true, so it can be dropped. Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-12-02gcov: Remove compiler version checkNathan Chancellor
The minimum supported version of LLVM has been raised to 11.0.0, meaning this check is always true, so it can be dropped. Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-12-02Revert "ARM: 9070/1: Make UNWINDER_ARM depend on ld.bfd or ld.lld 11.0.0+"Nathan Chancellor
This reverts commit 7411cfc3c91a08a884463bbc7623087ecc2efdd8. The minimum supported version of LLVM has been raised to 11.0.0, meaning this check is always true, so it can be dropped. Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-12-02arch/Kconfig: Remove CLANG_VERSION check in HAS_LTO_CLANGNathan Chancellor
The minimum supported version of LLVM has been raised to 11.0.0, meaning this check is always true, so it can be dropped. Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-12-02mm, slab: Remove compiler check in __kmalloc_indexNathan Chancellor
The minimum supported version of LLVM has been raised to 11.0.0, meaning this check is always true, so it can be dropped. Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-12-02Documentation: Raise the minimum supported version of LLVM to 11.0.0Nathan Chancellor
LLVM versions prior to 11.0.0 have a harder time with dead code elimination, which can cause issues with commonly used expressions such as BUILD_BUG_ON and the bitmask functions/macros in bitfield.h (see the first two issues links below). Whenever there is an issue within LLVM that has been resolved in a later release, the only course of action is to gate the problematic configuration or source code on the toolchain verson or raise the minimum supported version of LLVM for building the kernel, as LLVM has a limited support lifetime compared to GCC. GCC major releases will typically see a few point releases across a two year period on average whereas LLVM major releases are only supported until the next major release and will only see one or two point releases within that timeframe. For example, GCC 8.1 was released in May 2018 and GCC 8.5 was released in May 2021, whereas LLVM 12.0.0 was released in April 2021 and its only point release, 12.0.1, was released in July 2021, giving a minimal window for fixes to be backported. To resolve these build errors around improper dead code elimination, raise the minimum supported version of LLVM for building the kernel to 11.0.0. Doing so is a more proper solution than mucking around with core kernel macros that have always worked with GCC or disabling drivers for using these macros in a proper manner. This type of issue may continue to crop up and require patching, which creates more debt for bumping the minimum supported version in the future. This should have a minimal impact to distributions. Using a script to pull several different Docker images and check the output of 'clang --version': archlinux:latest: clang version 13.0.0 debian:oldoldstable-slim: clang version 3.8.1-24 (tags/RELEASE_381/final) debian:oldstable-slim: clang version 7.0.1-8+deb10u2 (tags/RELEASE_701/final) debian:stable-slim: Debian clang version 11.0.1-2 debian:testing-slim: Debian clang version 11.1.0-4 debian:unstable-slim: Debian clang version 11.1.0-4 fedora:34: clang version 12.0.1 (Fedora 12.0.1-1.fc34) fedora:latest: clang version 13.0.0 (Fedora 13.0.0-3.fc35) fedora:rawhide: clang version 13.0.0 (Fedora 13.0.0-5.fc36) opensuse/leap:15.2: clang version 9.0.1 opensuse/leap:latest: clang version 11.0.1 opensuse/tumbleweed:latest: clang version 13.0.0 ubuntu:bionic: clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final) ubuntu:latest: clang version 10.0.0-4ubuntu1 ubuntu:hirsute: Ubuntu clang version 12.0.0-3ubuntu1~21.04.2 ubuntu:rolling: Ubuntu clang version 13.0.0-2 ubuntu:devel: Ubuntu clang version 13.0.0-9 In every case, the distribution's version of clang is either older than the current minimum supported version of LLVM 10.0.1 or equal to or greater than the proposed 11.0.0 so nothing should change. Another benefit of this change is LLVM=1 works better with arm64 and x86_64 since commit f12b034afeb3 ("scripts/Makefile.clang: default to LLVM_IAS=1") enabled the integrated assembler by default, which only works well with clang 11+ (clang-10 required it to be disabled to successfully build a kernel). Link: https://github.com/ClangBuiltLinux/linux/issues/1293 Link: https://github.com/ClangBuiltLinux/linux/issues/1506 Link: https://github.com/ClangBuiltLinux/linux/issues/1511 Link: https://github.com/llvm/llvm-project/commit/fa496ce3c6774097080c8a9cb808da56f383b938 Link: https://groups.google.com/g/clang-built-linux/c/mPQb9_ZWW0s/m/W7o6S-QTBAAJ Link: https://github.com/ClangBuiltLinux/misc-scripts Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-12-02streamline_config.pl: show the full Kconfig nameŁukasz Stelmach
Show the very same file name that was passed to open() in case the operation failed. Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
2021-12-02kconfig: Add `make mod2noconfig` to disable module optionsJosh Triplett
When converting a modular kernel to a monolithic kernel, once the kernel works without loading any modules, this helps to quickly disable all the modules before turning off module support entirely. Refactor conf_rewrite_mod_or_yes to a more general conf_rewrite_tristates that accepts an old and new state. Signed-off-by: Josh Triplett <josh@joshtriplett.org> Tested-by: Björn Töpel <bjorn@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-11-28Linux 5.16-rc3Linus Torvalds
2021-11-28Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostLinus Torvalds
Pull vhost,virtio,vdpa bugfixes from Michael Tsirkin: "Misc fixes all over the place. Revert of virtio used length validation series: the approach taken does not seem to work, breaking too many guests in the process. We'll need to do length validation using some other approach" [ This merge also ends up reverting commit f7a36b03a732 ("vsock/virtio: suppress used length validation"), which came in through the networking tree in the meantime, and was part of that whole used length validation series - Linus ] * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: vdpa_sim: avoid putting an uninitialized iova_domain vhost-vdpa: clean irqs before reseting vdpa device virtio-blk: modify the value type of num in virtio_queue_rq() vhost/vsock: cleanup removing `len` variable vhost/vsock: fix incorrect used length reported to the guest Revert "virtio_ring: validate used buffer length" Revert "virtio-net: don't let virtio core to validate used length" Revert "virtio-blk: don't let virtio core to validate used length" Revert "virtio-scsi: don't let virtio core to validate used buffer length"
2021-11-28Merge tag 'x86-urgent-2021-11-28' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 build fix from Thomas Gleixner: "A single fix for a missing __init annotation of prepare_command_line()" * tag 'x86-urgent-2021-11-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/boot: Mark prepare_command_line() __init
2021-11-28Merge tag 'sched-urgent-2021-11-28' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fix from Thomas Gleixner: "A single scheduler fix to ensure that there is no stale KASAN shadow state left on the idle task's stack when a CPU is brought up after it was brought down before" * tag 'sched-urgent-2021-11-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/scs: Reset task stack state in bringup_cpu()
2021-11-28Merge tag 'perf-urgent-2021-11-28' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fix from Thomas Gleixner: "A single fix for perf to prevent it from sending SIGTRAP to another task from a trace point event as it's not possible to deliver a synchronous signal to a different task from there" * tag 'perf-urgent-2021-11-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf: Ignore sigtrap for tracepoints destined for other tasks
2021-11-28Merge tag 'locking-urgent-2021-11-28' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull locking fixes from Thomas Gleixner: "Two regression fixes for reader writer semaphores: - Plug a race in the lock handoff which is caused by inconsistency of the reader and writer path and can lead to corruption of the underlying counter. - down_read_trylock() is suboptimal when the lock is contended and multiple readers trylock concurrently. That's due to the initial value being read non-atomically which results in at least two compare exchange loops. Making the initial readout atomic reduces this significantly. Whith 40 readers by 11% in a benchmark which enforces contention on mmap_sem" * tag 'locking-urgent-2021-11-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: locking/rwsem: Optimize down_read_trylock() under highly contended case locking/rwsem: Make handoff bit handling more consistent
2021-11-28Merge tag 'trace-v5.16-rc2-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull another tracing fix from Steven Rostedt: "Fix the fix of pid filtering The setting of the pid filtering flag tested the "trace only this pid" case twice, and ignored the "trace everything but this pid" case. The 5.15 kernel does things a little differently due to the new sparse pid mask introduced in 5.16, and as the bug was discovered running the 5.15 kernel, and the first fix was initially done for that kernel, that fix handled both cases (only pid and all but pid), but the forward port to 5.16 created this bug" * tag 'trace-v5.16-rc2-3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: tracing: Test the 'Do not trace this pid' case in create event
2021-11-28Merge tag 'iommu-fixes-v5.16-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu Pull iommu fixes from Joerg Roedel: - Intel VT-d fixes: - Remove unused PASID_DISABLED - Fix RCU locking - Fix for the unmap_pages call-back - Rockchip RK3568 address mask fix - AMD IOMMUv2 log message clarification * tag 'iommu-fixes-v5.16-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: iommu/vt-d: Fix unmap_pages support iommu/vt-d: Fix an unbalanced rcu_read_lock/rcu_read_unlock() iommu/rockchip: Fix PAGE_DESC_HI_MASKs for RK3568 iommu/amd: Clarify AMD IOMMUv2 initialization messages iommu/vt-d: Remove unused PASID_DISABLED
2021-11-27Merge tag '5.16-rc2-ksmbd-fixes' of git://git.samba.org/ksmbdLinus Torvalds
Pull ksmbd fixes from Steve French: "Five ksmbd server fixes, four of them for stable: - memleak fix - fix for default data stream on filesystems that don't support xattr - error logging fix - session setup fix - minor doc cleanup" * tag '5.16-rc2-ksmbd-fixes' of git://git.samba.org/ksmbd: ksmbd: fix memleak in get_file_stream_info() ksmbd: contain default data stream even if xattr is empty ksmbd: downgrade addition info error msg to debug in smb2_get_info_sec() docs: filesystem: cifs: ksmbd: Fix small layout issues ksmbd: Fix an error handling path in 'smb2_sess_setup()'
2021-11-27vmxnet3: Use generic Kconfig option for page size limitGuenter Roeck
Use the architecture independent Kconfig option PAGE_SIZE_LESS_THAN_64KB to indicate that VMXNET3 requires a page size smaller than 64kB. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-11-27fs: ntfs: Limit NTFS_RW to page sizes smaller than 64kGuenter Roeck
NTFS_RW code allocates page size dependent arrays on the stack. This results in build failures if the page size is 64k or larger. fs/ntfs/aops.c: In function 'ntfs_write_mst_block': fs/ntfs/aops.c:1311:1: error: the frame size of 2240 bytes is larger than 2048 bytes Since commit f22969a66041 ("powerpc/64s: Default to 64K pages for 64 bit book3s") this affects ppc:allmodconfig builds, but other architectures supporting page sizes of 64k or larger are also affected. Increasing the maximum frame size for affected architectures just to silence this error does not really help. The frame size would have to be set to a really large value for 256k pages. Also, a large frame size could potentially result in stack overruns in this code and elsewhere and is therefore not desirable. Make NTFS_RW dependent on page sizes smaller than 64k instead. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Cc: Anton Altaparmakov <anton@tuxera.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-11-27arch: Add generic Kconfig option indicating page size smaller than 64kGuenter Roeck
NTFS_RW and VMXNET3 require a page size smaller than 64kB. Add generic Kconfig option for use outside architecture code to avoid architecture specific Kconfig options in that code. Suggested-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Cc: Anton Altaparmakov <anton@tuxera.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-11-27tracing: Test the 'Do not trace this pid' case in create eventSteven Rostedt (VMware)
When creating a new event (via a module, kprobe, eprobe, etc), the descriptors that are created must add flags for pid filtering if an instance has pid filtering enabled, as the flags are used at the time the event is executed to know if pid filtering should be done or not. The "Only trace this pid" case was added, but a cut and paste error made that case checked twice, instead of checking the "Trace all but this pid" case. Link: https://lore.kernel.org/all/202111280401.qC0z99JB-lkp@intel.com/ Fixes: 6cb206508b62 ("tracing: Check pid filtering when creating events") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2021-11-27Merge tag 'xfs-5.16-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds
Pull xfs fixes from Darrick Wong: "Fixes for a resource leak and a build robot complaint about totally dead code: - Fix buffer resource leak that could lead to livelock on corrupt fs. - Remove unused function xfs_inew_wait to shut up the build robots" * tag 'xfs-5.16-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: xfs: remove xfs_inew_wait xfs: Fix the free logic of state in xfs_attr_node_hasname
2021-11-27Merge tag 'iomap-5.16-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds
Pull iomap fixes from Darrick Wong: "A single iomap bug fix and a cleanup for 5.16-rc2. The bug fix changes how iomap deals with reading from an inline data region -- whereas the current code (incorrectly) lets the iomap read iter try for more bytes after reading the inline region (which zeroes the rest of the page!) and hopes the next iteration terminates, we surveyed the inlinedata implementations and realized that all inlinedata implementations also require that the inlinedata region end at EOF, so we can simply terminate the read. The second patch documents these assumptions in the code so that they're not subtle implications anymore, and cleans up some of the grosser parts of that function. Summary: - Fix an accounting problem where unaligned inline data reads can run off the end of the read iomap iterator. iomap has historically required that inline data mappings only exist at the end of a file, though this wasn't documented anywhere. - Document iomap_read_inline_data and change its return type to be appropriate for the information that it's actually returning" * tag 'iomap-5.16-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: iomap: iomap_read_inline_data cleanup iomap: Fix inline extent handling in iomap_readpage
2021-11-27Merge tag 'trace-v5.16-rc2-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull tracing fixes from Steven Rostedt: "Two fixes to event pid filtering: - Make sure newly created events reflect the current state of pid filtering - Take pid filtering into account when recording trigger events. (Also clean up the if statement to be cleaner)" * tag 'trace-v5.16-rc2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: tracing: Fix pid filtering when triggers are attached tracing: Check pid filtering when creating events
2021-11-27Merge tag 'io_uring-5.16-2021-11-27' of git://git.kernel.dk/linux-blockLinus Torvalds
Pull more io_uring fixes from Jens Axboe: "The locking fixup that was applied earlier this rc has both a deadlock and IRQ safety issue, let's get that ironed out before -rc3. This contains: - Link traversal locking fix (Pavel) - Cancelation fix (Pavel) - Relocate cond_resched() for huge buffer chain freeing, avoiding a softlockup warning (Ye) - Fix timespec validation (Ye)" * tag 'io_uring-5.16-2021-11-27' of git://git.kernel.dk/linux-block: io_uring: Fix undefined-behaviour in io_issue_sqe io_uring: fix soft lockup when call __io_remove_buffers io_uring: fix link traversal locking io_uring: fail cancellation for EXITING tasks
2021-11-27Merge tag 'block-5.16-2021-11-27' of git://git.kernel.dk/linux-blockLinus Torvalds
Pull more block fixes from Jens Axboe: "Turns out that the flushing out of pending fixes before the Thanksgiving break didn't quite work out in terms of timing, so here's a followup set of fixes: - rq_qos_done() should be called regardless of whether or not we're the final put of the request, it's not related to the freeing of the state. This fixes an IO stall with wbt that a few users have reported, a regression in this release. - Only define zram_wb_devops if it's used, fixing a compilation warning for some compilers" * tag 'block-5.16-2021-11-27' of git://git.kernel.dk/linux-block: zram: only make zram_wb_devops for CONFIG_ZRAM_WRITEBACK block: call rq_qos_done() before ref check in batch completions
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-27 11:35:02 +0000