summaryrefslogtreecommitdiff
path: root/scripts
AgeCommit message (Collapse)Author
2025-06-04kbuild: fix argument parsing in scripts/configSeyediman Seyedarab
[ Upstream commit f757f6011c92b5a01db742c39149bed9e526478f ] The script previously assumed --file was always the first argument, which caused issues when it appeared later. This patch updates the parsing logic to scan all arguments to find --file, sets the config file correctly, and resets the argument list with the remaining commands. It also fixes --refresh to respect --file by passing KCONFIG_CONFIG=$FN to make oldconfig. Signed-off-by: Seyediman Seyedarab <imandevel@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-04kconfig: merge_config: use an empty file as initfileDaniel Gomez
[ Upstream commit a26fe287eed112b4e21e854f173c8918a6a8596d ] The scripts/kconfig/merge_config.sh script requires an existing $INITFILE (or the $1 argument) as a base file for merging Kconfig fragments. However, an empty $INITFILE can serve as an initial starting point, later referenced by the KCONFIG_ALLCONFIG Makefile variable if -m is not used. This variable can point to any configuration file containing preset config symbols (the merged output) as stated in Documentation/kbuild/kconfig.rst. When -m is used $INITFILE will contain just the merge output requiring the user to run make (i.e. KCONFIG_ALLCONFIG=<$INITFILE> make <allnoconfig/alldefconfig> or make olddefconfig). Instead of failing when `$INITFILE` is missing, create an empty file and use it as the starting point for merges. Signed-off-by: Daniel Gomez <da.gomez@samsung.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-02objtool: Silence more KCOV warnings, part 2Josh Poimboeuf
commit 55c78035a1a8dfb05f1472018ce2a651701adb7d upstream. Similar to GCOV, KCOV can leave behind dead code and undefined behavior. Warnings related to those should be ignored. The previous commit: 6b023c784204 ("objtool: Silence more KCOV warnings") ... only did so for CONFIG_CGOV_KERNEL. Also do it for CONFIG_KCOV, but for real this time. Fixes the following warning: vmlinux.o: warning: objtool: synaptics_report_mt_data: unexpected end of section .text.synaptics_report_mt_data Fixes: 6b023c784204 ("objtool: Silence more KCOV warnings") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/a44ba16e194bcbc52c1cef3d3cd9051a62622723.1743481539.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/oe-kbuild-all/202503282236.UhfRsF3B-lkp@intel.com/ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-25sign-file,extract-cert: use pkcs11 provider for OPENSSL MAJOR >= 3Jan Stancek
commit 558bdc45dfb2669e1741384a0c80be9c82fa052c upstream. ENGINE API has been deprecated since OpenSSL version 3.0 [1]. Distros have started dropping support from headers and in future it will likely disappear also from library. It has been superseded by the PROVIDER API, so use it instead for OPENSSL MAJOR >= 3. [1] https://github.com/openssl/openssl/blob/master/README-ENGINES.md [jarkko: fixed up alignment issues reported by checkpatch.pl --strict] Signed-off-by: Jan Stancek <jstancek@redhat.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: R Nageswara Sastry <rnsastry@linux.ibm.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-25sign-file,extract-cert: avoid using deprecated ERR_get_error_line()Jan Stancek
commit 467d60eddf55588add232feda325da7215ddaf30 upstream. ERR_get_error_line() is deprecated since OpenSSL 3.0. Use ERR_peek_error_line() instead, and combine display_openssl_errors() and drain_openssl_errors() to a single function where parameter decides if it should consume errors silently. Signed-off-by: Jan Stancek <jstancek@redhat.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: R Nageswara Sastry <rnsastry@linux.ibm.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-25sign-file,extract-cert: move common SSL helper functions to a headerJan Stancek
commit 300e6d4116f956b035281ec94297dc4dc8d4e1d3 upstream. Couple error handling helpers are repeated in both tools, so move them to a common header. Signed-off-by: Jan Stancek <jstancek@redhat.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: R Nageswara Sastry <rnsastry@linux.ibm.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-10selinux: Chain up tool resolving errors in install_policy.shTim Schumacher
[ Upstream commit 6ae0042f4d3f331e841495eb0a3d51598e593ec2 ] Subshell evaluations are not exempt from errexit, so if a command is not available, `which` will fail and exit the script as a whole. This causes the helpful error messages to not be printed if they are tacked on using a `$?` comparison. Resolve the issue by using chains of logical operators, which are not subject to the effects of errexit. Fixes: e37c1877ba5b1 ("scripts/selinux: modernize mdp") Signed-off-by: Tim Schumacher <tim.schumacher1@huawei.com> Signed-off-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-22scripts: generate_rust_analyzer: add missing macros depsTamir Duberstein
[ Upstream commit 2e0f91aba507a3cb59f7a12fc3ea2b7d4d6675b7 ] The macros crate has depended on std and proc_macro since its introduction in commit 1fbde52bde73 ("rust: add `macros` crate"). These dependencies were omitted from commit 8c4555ccc55c ("scripts: add `generate_rust_analyzer.py`") resulting in missing go-to-definition and autocomplete, and false-positive warnings emitted from rust-analyzer such as: [{ "resource": "/Users/tamird/src/linux/rust/macros/module.rs", "owner": "_generated_diagnostic_collection_name_#1", "code": { "value": "non_snake_case", "target": { "$mid": 1, "path": "/rustc/", "scheme": "https", "authority": "doc.rust-lang.org", "query": "search=non_snake_case" } }, "severity": 4, "message": "Variable `None` should have snake_case name, e.g. `none`", "source": "rust-analyzer", "startLineNumber": 123, "startColumn": 17, "endLineNumber": 123, "endColumn": 21 }] Add the missing dependencies to improve the developer experience. [ Fiona had a different approach (thanks!) at: https://lore.kernel.org/rust-for-linux/20241205115438.234221-1-me@kloenk.dev/ But Tamir and Fiona agreed to this one. - Miguel ] Fixes: 8c4555ccc55c ("scripts: add `generate_rust_analyzer.py`") Reviewed-by: Fiona Behrens <me@kloenk.dev> Diagnosed-by: Chayim Refael Friedman <chayimfr@gmail.com> Link: https://github.com/rust-lang/rust-analyzer/issues/17759#issuecomment-2646328275 Signed-off-by: Tamir Duberstein <tamird@gmail.com> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250210-rust-analyzer-macros-core-dep-v3-1-45eb4836f218@gmail.com [ Removed `return`. Changed tag name. Added Link. Slightly reworded. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-17scripts/gdb: fix aarch64 userspace detection in get_current_taskJan Kiszka
commit 4ebc417ef9cb34010a71270421fe320ec5d88aa2 upstream. At least recent gdb releases (seen with 14.2) return SP_EL0 as signed long which lets the right-shift always return 0. Link: https://lkml.kernel.org/r/dcd2fabc-9131-4b48-8419-6444e2d67454@siemens.com Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Cc: Barry Song <baohua@kernel.org> Cc: Kieran Bingham <kbingham@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-17kbuild: Move -Wenum-enum-conversion to W=2Nathan Chancellor
commit 8f6629c004b193d23612641c3607e785819e97ab upstream. -Wenum-enum-conversion was strengthened in clang-19 to warn for C, which caused the kernel to move it to W=1 in commit 75b5ab134bb5 ("kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1") because there were numerous instances that would break builds with -Werror. Unfortunately, this is not a full solution, as more and more developers, subsystems, and distributors are building with W=1 as well, so they continue to see the numerous instances of this warning. Since the move to W=1, there have not been many new instances that have appeared through various build reports and the ones that have appeared seem to be following similar existing patterns, suggesting that most instances of this warning will not be real issues. The only alternatives for silencing this warning are adding casts (which is generally seen as an ugly practice) or refactoring the enums to macro defines or a unified enum (which may be undesirable because of type safety in other parts of the code). Move the warning to W=2, where warnings that occur frequently but may be relevant should reside. Cc: stable@vger.kernel.org Fixes: 75b5ab134bb5 ("kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1") Link: https://lore.kernel.org/ZwRA9SOcOjjLJcpi@google.com/ Signed-off-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-08kbuild: switch from lz4c to lz4 for compressionParth Pancholi
commit e397a603e49cc7c7c113fad9f55a09637f290c34 upstream. Replace lz4c with lz4 for kernel image compression. Although lz4 and lz4c are functionally similar, lz4c has been deprecated upstream since 2018. Since as early as Ubuntu 16.04 and Fedora 25, lz4 and lz4c have been packaged together, making it safe to update the requirement from lz4c to lz4. Consequently, some distributions and build systems, such as OpenEmbedded, have fully transitioned to using lz4. OpenEmbedded core adopted this change in commit fe167e082cbd ("bitbake.conf: require lz4 instead of lz4c"), causing compatibility issues when building the mainline kernel in the latest OpenEmbedded environment, as seen in the errors below. This change also updates the LZ4 compression commands to make it backward compatible by replacing stdin and stdout with the '-' option, due to some unclear reason, the stdout keyword does not work for lz4 and '-' works for both. In addition, this modifies the legacy '-c1' with '-9' which is also compatible with both. This fixes the mainline kernel build failures with the latest master OpenEmbedded builds associated with the mentioned compatibility issues. LZ4 arch/arm/boot/compressed/piggy_data /bin/sh: 1: lz4c: not found ... ... ERROR: oe_runmake failed Link: https://github.com/lz4/lz4/pull/553 Suggested-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Parth Pancholi <parth.pancholi@toradex.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Cc: Salvatore Bonaccorso <carnil@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-08kconfig: fix memory leak in sym_warn_unmet_dep()Masahiro Yamada
[ Upstream commit a409fc1463d664002ea9bf700ae4674df03de111 ] The string allocated in sym_warn_unmet_dep() is never freed, leading to a memory leak when an unmet dependency is detected. Fixes: f8f69dc0b4e0 ("kconfig: make unmet dependency warnings readable") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Petr Vorel <pvorel@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08kconfig: WERROR unmet symbol dependencySergey Senozhatsky
[ Upstream commit 15d3f7664d2776c086f813f1efbfe2ae20a85e89 ] When KCONFIG_WERROR env variable is set treat unmet direct symbol dependency as a terminal condition (error). Suggested-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Stable-dep-of: a409fc1463d6 ("kconfig: fix memory leak in sym_warn_unmet_dep()") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08kconfig: deduplicate code in conf_read_simple()Masahiro Yamada
[ Upstream commit d854b4b21de684a16a7d6163c7b0e9c5ff8a09d3 ] Kconfig accepts both "# CONFIG_FOO is not set" and "CONFIG_FOO=n" as a valid input, but conf_read_simple() duplicates similar code to handle them. Factor out the common code. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Stable-dep-of: a409fc1463d6 ("kconfig: fix memory leak in sym_warn_unmet_dep()") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08kconfig: remove unused code for S_DEF_AUTO in conf_read_simple()Masahiro Yamada
[ Upstream commit 92d4fe0a48f1ab6cf20143dd0b376f4fe842854b ] The 'else' arm here is unreachable in practical use cases. include/config/auto.conf does not include "# CONFIG_... is not set" line unless it is manually hacked. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Stable-dep-of: a409fc1463d6 ("kconfig: fix memory leak in sym_warn_unmet_dep()") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08kconfig: require a space after '#' for valid inputMasahiro Yamada
[ Upstream commit 4d137ab0107ead0f2590fc0314e627431e3b9e3f ] Currently, when an input line starts with '#', (line + 2) is passed to memcmp() without checking line[1]. It means that line[1] can be any arbitrary character. For example, "#KCONFIG_FOO is not set" is accepted as valid input, functioning the same as "# CONFIG_FOO is not set". More importantly, this can potentially lead to a buffer overrun if line[1] == '\0'. It occurs if the input only contains '#', as (line + 2) points to an uninitialized buffer. Check line[1], and skip the line if it is not a space. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Stable-dep-of: a409fc1463d6 ("kconfig: fix memory leak in sym_warn_unmet_dep()") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08kconfig: fix file name in warnings when loading KCONFIG_DEFCONFIG_LISTMasahiro Yamada
[ Upstream commit a314f52a0210730d0d556de76bb7388e76d4597d ] Most 'make *config' commands use .config as the base configuration file. When .config does not exist, Kconfig tries to load a file listed in KCONFIG_DEFCONFIG_LIST instead. However, since commit b75b0a819af9 ("kconfig: change defconfig_list option to environment variable"), warning messages have displayed an incorrect file name in such cases. Below is a demonstration using Debian Trixie. While loading /boot/config-6.12.9-amd64, the warning messages incorrectly show .config as the file name. With this commit, the correct file name is displayed in warnings. [Before] $ rm -f .config $ make config # # using defaults found in /boot/config-6.12.9-amd64 # .config:6804:warning: symbol value 'm' invalid for FB_BACKLIGHT .config:9895:warning: symbol value 'm' invalid for ANDROID_BINDER_IPC [After] $ rm -f .config $ make config # # using defaults found in /boot/config-6.12.9-amd64 # /boot/config-6.12.9-amd64:6804:warning: symbol value 'm' invalid for FB_BACKLIGHT /boot/config-6.12.9-amd64:9895:warning: symbol value 'm' invalid for ANDROID_BINDER_IPC Fixes: b75b0a819af9 ("kconfig: change defconfig_list option to environment variable") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08genksyms: fix memory leak when the same symbol is read from *.symref fileMasahiro Yamada
[ Upstream commit be2fa44b5180a1f021efb40c55fdf63c249c3209 ] When a symbol that is already registered is read again from *.symref file, __add_symbol() removes the previous one from the hash table without freeing it. [Test Case] $ cat foo.c #include <linux/export.h> void foo(void); void foo(void) {} EXPORT_SYMBOL(foo); $ cat foo.symref foo void foo ( void ) foo void foo ( void ) When a symbol is removed from the hash table, it must be freed along with its ->name and ->defn members. However, sym->name cannot be freed because it is sometimes shared with node->string, but not always. If sym->name and node->string share the same memory, free(sym->name) could lead to a double-free bug. To resolve this issue, always assign a strdup'ed string to sym->name. Fixes: 64e6c1e12372 ("genksyms: track symbol checksum changes") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08genksyms: fix memory leak when the same symbol is added from sourceMasahiro Yamada
[ Upstream commit 45c9c4101d3d2fdfa00852274bbebba65fcc3cf2 ] When a symbol that is already registered is added again, __add_symbol() returns without freeing the symbol definition, making it unreachable. The following test cases demonstrate different memory leak points. [Test Case 1] Forward declaration with exactly the same definition $ cat foo.c #include <linux/export.h> void foo(void); void foo(void) {} EXPORT_SYMBOL(foo); [Test Case 2] Forward declaration with a different definition (e.g. attribute) $ cat foo.c #include <linux/export.h> void foo(void); __attribute__((__section__(".ref.text"))) void foo(void) {} EXPORT_SYMBOL(foo); [Test Case 3] Preserving an overridden symbol (compile with KBUILD_PRESERVE=1) $ cat foo.c #include <linux/export.h> void foo(void); void foo(void) { } EXPORT_SYMBOL(foo); $ cat foo.symref override foo void foo ( int ) The memory leaks in Test Case 1 and 2 have existed since the introduction of genksyms into the kernel tree. [1] The memory leak in Test Case 3 was introduced by commit 5dae9a550a74 ("genksyms: allow to ignore symbol checksum changes"). When multiple init_declarators are reduced to an init_declarator_list, the decl_spec must be duplicated. Otherwise, the following Test Case 4 would result in a double-free bug. [Test Case 4] $ cat foo.c #include <linux/export.h> extern int foo, bar; int foo, bar; EXPORT_SYMBOL(foo); In this case, 'foo' and 'bar' share the same decl_spec, 'int'. It must be unshared before being passed to add_symbol(). [1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=46bd1da672d66ccd8a639d3c1f8a166048cca608 Fixes: 5dae9a550a74 ("genksyms: allow to ignore symbol checksum changes") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-01-09scripts/sorttable: fix orc_sort_cmp() to maintain symmetry and transitivityKuan-Wei Chiu
commit 0210d251162f4033350a94a43f95b1c39ec84a90 upstream. The orc_sort_cmp() function, used with qsort(), previously violated the symmetry and transitivity rules required by the C standard. Specifically, when both entries are ORC_TYPE_UNDEFINED, it could result in both a < b and b < a, which breaks the required symmetry and transitivity. This can lead to undefined behavior and incorrect sorting results, potentially causing memory corruption in glibc implementations [1]. Symmetry: If x < y, then y > x. Transitivity: If x < y and y < z, then x < z. Fix the comparison logic to return 0 when both entries are ORC_TYPE_UNDEFINED, ensuring compliance with qsort() requirements. Link: https://www.qualys.com/2024/01/30/qsort.txt [1] Link: https://lkml.kernel.org/r/20241226140332.2670689-1-visitorckw@gmail.com Fixes: 57fa18994285 ("scripts/sorttable: Implement build-time ORC unwind table sorting") Fixes: fb799447ae29 ("x86,objtool: Split UNWIND_HINT_EMPTY in two") Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com> Cc: Ching-Chun (Jim) Huang <jserv@ccns.ncku.edu.tw> Cc: <chuang@cs.nycu.edu.tw> Cc: Ingo Molnar <mingo@kernel.org> Cc: Josh Poimboeuf <jpoimboe@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Shile Zhang <shile.zhang@linux.alibaba.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-09modpost: fix the missed iteration for the max bit in do_input()Masahiro Yamada
[ Upstream commit bf36b4bf1b9a7a0015610e2f038ee84ddb085de2 ] This loop should iterate over the range from 'min' to 'max' inclusively. The last interation is missed. Fixes: 1d8f430c15b3 ("[PATCH] Input: add modalias support") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-01-09modpost: fix input MODULE_DEVICE_TABLE() built for 64-bit on 32-bit hostMasahiro Yamada
[ Upstream commit 77dc55a978e69625f9718460012e5ef0172dc4de ] When building a 64-bit kernel on a 32-bit build host, incorrect input MODULE_ALIAS() entries may be generated. For example, when compiling a 64-bit kernel with CONFIG_INPUT_MOUSEDEV=m on a 64-bit build machine, you will get the correct output: $ grep MODULE_ALIAS drivers/input/mousedev.mod.c MODULE_ALIAS("input:b*v*p*e*-e*1,*2,*k*110,*r*0,*1,*a*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*2,*k*r*8,*a*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*3,*k*14A,*r*a*0,*1,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*3,*k*145,*r*a*0,*1,*18,*1C,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*3,*k*110,*r*a*0,*1,*m*l*s*f*w*"); However, building the same kernel on a 32-bit machine results in incorrect output: $ grep MODULE_ALIAS drivers/input/mousedev.mod.c MODULE_ALIAS("input:b*v*p*e*-e*1,*2,*k*110,*130,*r*0,*1,*a*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*2,*k*r*8,*a*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*3,*k*14A,*16A,*r*a*0,*1,*20,*21,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*3,*k*145,*165,*r*a*0,*1,*18,*1C,*20,*21,*38,*3C,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*3,*k*110,*130,*r*a*0,*1,*20,*21,*m*l*s*f*w*"); A similar issue occurs with CONFIG_INPUT_JOYDEV=m. On a 64-bit build machine, the output is: $ grep MODULE_ALIAS drivers/input/joydev.mod.c MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*0,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*2,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*8,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*6,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*k*120,*r*a*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*k*130,*r*a*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*k*2C0,*r*a*m*l*s*f*w*"); However, on a 32-bit machine, the output is incorrect: $ grep MODULE_ALIAS drivers/input/joydev.mod.c MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*0,*20,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*2,*22,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*8,*28,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*3,*k*r*a*6,*26,*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*k*11F,*13F,*r*a*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*k*11F,*13F,*r*a*m*l*s*f*w*"); MODULE_ALIAS("input:b*v*p*e*-e*1,*k*2C0,*2E0,*r*a*m*l*s*f*w*"); When building a 64-bit kernel, BITS_PER_LONG is defined as 64. However, on a 32-bit build machine, the constant 1L is a signed 32-bit value. Left-shifting it beyond 32 bits causes wraparound, and shifting by 31 or 63 bits makes it a negative value. The fix in commit e0e92632715f ("[PATCH] PATCH: 1 line 2.6.18 bugfix: modpost-64bit-fix.patch") is incorrect; it only addresses cases where a 64-bit kernel is built on a 64-bit build machine, overlooking cases on a 32-bit build machine. Using 1ULL ensures a 64-bit width on both 32-bit and 64-bit machines, avoiding the wraparound issue. Fixes: e0e92632715f ("[PATCH] PATCH: 1 line 2.6.18 bugfix: modpost-64bit-fix.patch") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Stable-dep-of: bf36b4bf1b9a ("modpost: fix the missed iteration for the max bit in do_input()") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-14setlocalversion: work around "git describe" performanceRasmus Villemoes
[ Upstream commit 523f3dbc187a9618d4fd80c2b438e4d490705dcd ] Contrary to expectations, passing a single candidate tag to "git describe" is slower than not passing any --match options. $ time git describe --debug ... traversed 10619 commits ... v6.12-rc5-63-g0fc810ae3ae1 real 0m0.169s $ time git describe --match=v6.12-rc5 --debug ... traversed 1310024 commits v6.12-rc5-63-g0fc810ae3ae1 real 0m1.281s In fact, the --debug output shows that git traverses all or most of history. For some repositories and/or git versions, those 1.3s are actually 10-15 seconds. This has been acknowledged as a performance bug in git [1], and a fix is on its way [2]. However, no solution is yet in git.git, and even when one lands, it will take quite a while before it finds its way to a release and for $random_kernel_developer to pick that up. So rewrite the logic to use plumbing commands. For each of the candidate values of $tag, we ask: (1) is $tag even an annotated tag? (2) Is it eligible to describe HEAD, i.e. an ancestor of HEAD? (3) If so, how many commits are in $tag..HEAD? I have tested that this produces the same output as the current script for ~700 random commits between v6.9..v6.10. For those 700 commits, and in my git repo, the 'make -s kernelrelease' command is on average ~4 times faster with this patch applied (geometric mean of ratios). For the commit mentioned in Josh's original report [3], the time-consuming part of setlocalversion goes from $ time git describe --match=v6.12-rc5 c1e939a21eb1 v6.12-rc5-44-gc1e939a21eb1 real 0m1.210s to $ time git rev-list --count --left-right v6.12-rc5..c1e939a21eb1 0 44 real 0m0.037s [1] https://lore.kernel.org/git/20241101113910.GA2301440@coredump.intra.peff.net/ [2] https://lore.kernel.org/git/20241106192236.GC880133@coredump.intra.peff.net/ [3] https://lore.kernel.org/lkml/309549cafdcfe50c4fceac3263220cc3d8b109b2.1730337435.git.jpoimboe@kernel.org/ Reported-by: Sean Christopherson <seanjc@google.com> Closes: https://lore.kernel.org/lkml/ZPtlxmdIJXOe0sEy@google.com/ Reported-by: Josh Poimboeuf <jpoimboe@kernel.org> Closes: https://lore.kernel.org/lkml/309549cafdcfe50c4fceac3263220cc3d8b109b2.1730337435.git.jpoimboe@kernel.org/ Tested-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-14modpost: Add .irqentry.text to OTHER_SECTIONSThomas Gleixner
commit 7912405643a14b527cd4a4f33c1d4392da900888 upstream. The compiler can fully inline the actual handler function of an interrupt entry into the .irqentry.text entry point. If such a function contains an access which has an exception table entry, modpost complains about a section mismatch: WARNING: vmlinux.o(__ex_table+0x447c): Section mismatch in reference ... The relocation at __ex_table+0x447c references section ".irqentry.text" which is not in the list of authorized sections. Add .irqentry.text to OTHER_SECTIONS to cure the issue. Reported-by: Sergey Senozhatsky <senozhatsky@chromium.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org # needed for linux-5.4-y Link: https://lore.kernel.org/all/20241128111844.GE10431@google.com/ Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-12-09modpost: remove incorrect code in do_eisa_entry()Masahiro Yamada
[ Upstream commit 0c3e091319e4748cb36ac9a50848903dc6f54054 ] This function contains multiple bugs after the following commits:  - ac551828993e ("modpost: i2c aliases need no trailing wildcard")  - 6543becf26ff ("mod/file2alias: make modalias generation safe for cross compiling") Commit ac551828993e inserted the following code to do_eisa_entry():     else             strcat(alias, "*"); This is incorrect because 'alias' is uninitialized. If it is not NULL-terminated, strcat() could cause a buffer overrun. Even if 'alias' happens to be zero-filled, it would output: MODULE_ALIAS("*"); This would match anything. As a result, the module could be loaded by any unrelated uevent from an unrelated subsystem. Commit ac551828993e introduced another bug.             Prior to that commit, the conditional check was:     if (eisa->sig[0]) This checked if the first character of eisa_device_id::sig was not '\0'. However, commit ac551828993e changed it as follows:     if (sig[0]) sig[0] is NOT the first character of the eisa_device_id::sig. The type of 'sig' is 'char (*)[8]', meaning that the type of 'sig[0]' is 'char [8]' instead of 'char'. 'sig[0]' and 'symval' refer to the same address, which never becomes NULL. The correct conversion would have been:     if ((*sig)[0]) However, this if-conditional was meaningless because the earlier change in commit ac551828993e was incorrect. This commit removes the entire incorrect code, which should never have been executed. Fixes: ac551828993e ("modpost: i2c aliases need no trailing wildcard") Fixes: 6543becf26ff ("mod/file2alias: make modalias generation safe for cross compiling") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-09init/modpost: conditionally check section mismatch to __meminit*Masahiro Yamada
[ Upstream commit 73db3abdca58c8a014ec4c88cf5ef925cbf63669 ] This reverts commit eb8f689046b8 ("Use separate sections for __dev/ _cpu/__mem code/data"). Check section mismatch to __meminit* only when CONFIG_MEMORY_HOTPLUG=n. With this change, the linker script and modpost become simpler, and we can get rid of the __ref annotations from the memory hotplug code. [sfr@canb.auug.org.au: remove MEM_KEEP from arch/powerpc/kernel/vmlinux.lds.S] Link: https://lkml.kernel.org/r/20240710093213.2aefb25f@canb.auug.org.au Link: https://lkml.kernel.org/r/20240706160511.2331061-2-masahiroy@kernel.org Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Wei Yang <richard.weiyang@gmail.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Stable-dep-of: bb43a59944f4 ("Rename .data.unlikely to .data..unlikely") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-09modpost: squash ALL_{INIT,EXIT}_TEXT_SECTIONS to ALL_TEXT_SECTIONSMasahiro Yamada
[ Upstream commit 34fcf231dcf94d7dea29c070228c4b93849f4850 ] ALL_INIT_TEXT_SECTIONS and ALL_EXIT_TEXT_SECTIONS are only used in the macro definition of ALL_TEXT_SECTIONS. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Stable-dep-of: bb43a59944f4 ("Rename .data.unlikely to .data..unlikely") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-09modpost: use ALL_INIT_SECTIONS for the section check from DATA_SECTIONSMasahiro Yamada
[ Upstream commit e578e4e3110635b20786e442baa3aeff9bb65f95 ] ALL_INIT_SECTIONS is defined as follows: #define ALL_INIT_SECTIONS INIT_SECTIONS, ALL_XXXINIT_SECTIONS Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Stable-dep-of: bb43a59944f4 ("Rename .data.unlikely to .data..unlikely") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-09modpost: disallow the combination of EXPORT_SYMBOL and __meminit*Masahiro Yamada
[ Upstream commit a3df1526da480c089c20868b7f4d486b9f266001 ] Theoretically, we could export conditionally-discarded code sections, such as .meminit*, if all the users can become modular under a certain condition. However, that would be difficult to control and such a tricky case has never occurred. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Stable-dep-of: bb43a59944f4 ("Rename .data.unlikely to .data..unlikely") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-09modpost: remove EXIT_SECTIONS macroMasahiro Yamada
[ Upstream commit 48cd8df7afd1eef22cf7b125697a6d7c3d168c5c ] ALL_EXIT_SECTIONS and EXIT_SECTIONS are the same. Remove the latter. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Stable-dep-of: bb43a59944f4 ("Rename .data.unlikely to .data..unlikely") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-09modpost: remove MEM_INIT_SECTIONS macroMasahiro Yamada
[ Upstream commit 473a45bb35f080e31cb4fe45e905bfe3bd407fdf ] ALL_XXXINIT_SECTIONS and MEM_INIT_SECTIONS are the same. Remove the latter. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Stable-dep-of: bb43a59944f4 ("Rename .data.unlikely to .data..unlikely") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-09modpost: disallow *driver to reference .meminit* sectionsMasahiro Yamada
[ Upstream commit 50cccec15c48814765895891ca0d95d989b6a419 ] Drivers must not reference .meminit* sections, which are discarded when CONFIG_MEMORY_HOTPLUG=n. The reason for whitelisting "*driver" in the section mismatch check was to allow drivers to reference symbols annotated as __devinit or __devexit that existed in the past. Those annotations were removed by the following commits: - 54b956b90360 ("Remove __dev* markings from init.h") - 92e9e6d1f984 ("modpost.c: Stop checking __dev* section mismatches") Remove the stale whitelist. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Stable-dep-of: bb43a59944f4 ("Rename .data.unlikely to .data..unlikely") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-09modpost: remove ALL_EXIT_DATA_SECTIONS macroMasahiro Yamada
[ Upstream commit 3ada34b0f6559b2388f1983366614fbe8027b6fd ] This is unused. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Stable-dep-of: bb43a59944f4 ("Rename .data.unlikely to .data..unlikely") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-09checkpatch: always parse orig_commit in fixes tagTamir Duberstein
[ Upstream commit 2f07b652384969f5d0b317e1daa5f2eb967bc73d ] Do not require the presence of `$balanced_parens` to get the commit SHA; this allows a `Fixes: deadbeef` tag to get a correct suggestion rather than a suggestion containing a reference to HEAD. Given this patch: : From: Tamir Duberstein <tamird@gmail.com> : Subject: Test patch : Date: Fri, 25 Oct 2024 19:30:51 -0400 : : This is a test patch. : : Fixes: bd17e036b495 : Signed-off-by: Tamir Duberstein <tamird@gmail.com> : --- /dev/null : +++ b/new-file : @@ -0,0 +1 @@ : +Test. Before: WARNING: Please use correct Fixes: style 'Fixes: <12 chars of sha1> ("<title line>")' - ie: 'Fixes: c10a7d25e68f ("Test patch")' After: WARNING: Please use correct Fixes: style 'Fixes: <12 chars of sha1> ("<title line>")' - ie: 'Fixes: bd17e036b495 ("checkpatch: warn for non-standard fixes tag style")' The prior behavior incorrectly suggested the patch's own SHA and title line rather than the referenced commit's. This fixes that. Ironically this: Fixes: bd17e036b495 ("checkpatch: warn for non-standard fixes tag style") Signed-off-by: Tamir Duberstein <tamird@gmail.com> Cc: Andy Whitcroft <apw@canonical.com> Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Louis Peens <louis.peens@corigine.com> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com> Cc: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Cc: Philippe Schenker <philippe.schenker@toradex.com> Cc: Simon Horman <horms@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-09checkpatch: check for missing Fixes tagsDan Carpenter
[ Upstream commit d5d6281ae8e0c929c3ff188652f5b12c680fe8bf ] This check looks for common words that probably indicate a patch is a fix. For now the regex is: (?:(?:BUG: K.|UB)SAN: |Call Trace:|stable\@|syzkaller)/) Why are stable patches encouraged to have a fixes tag? Some people mark their stable patches as "# 5.10" etc. This is useful but a Fixes tag is still a good idea. For example, the Fixes tag helps in review. It helps people to not cherry-pick buggy patches without also cherry-picking the fix. Also if a bug affects the 5.7 kernel some people will round it up to 5.10+ because 5.7 is not supported on kernel.org. It's possible the Bad Binder bug was caused by this sort of gap where companies outside of kernel.org are supporting different kernels from kernel.org. Should it be counted as a Fix when a patch just silences harmless WARN_ON() stack trace. Yes. Definitely. Is silencing compiler warnings a fix? It seems unfair to the original authors, but we use -Werror now, and warnings break the build so let's just add Fixes tags. I tell people that silencing static checker warnings is not a fix but the rules on this vary by subsystem. Is fixing a minor LTP issue (Linux Test Project) a fix? Probably? It's hard to know what to do if the LTP test has technically always been broken. One clear false positive from this check is when someone updated their debug output and included before and after Call Traces. Or when crashes are introduced deliberately for testing. In those cases, you should just ignore checkpatch. Link: https://lkml.kernel.org/r/ZmhUgZBKeF_8ixA6@moroto Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Kees Cook <keescook@chromium.org> Cc: Andy Whitcroft <apw@canonical.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com> Cc: Sasha Levin <sashal@kernel.org> Cc: Thorsten Leemhuis <linux@leemhuis.info> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Stable-dep-of: 2f07b6523849 ("checkpatch: always parse orig_commit in fixes tag") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-10kconfig: qconf: fix buffer overflow in debug linksMasahiro Yamada
[ Upstream commit 984ed20ece1c6c20789ece040cbff3eb1a388fa9 ] If you enable "Option -> Show Debug Info" and click a link, the program terminates with the following error: *** buffer overflow detected ***: terminated The buffer overflow is caused by the following line: strcat(data, "$"); The buffer needs one more byte to accommodate the additional character. Fixes: c4f7398bee9c ("kconfig: qconf: make debug links work again") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-18scripts: kconfig: merge_config: config files: add a trailing newlineAnders Roxell
[ Upstream commit 33330bcf031818e60a816db0cfd3add9eecc3b28 ] When merging files without trailing newlines at the end of the file, two config fragments end up at the same row if file1.config doens't have a trailing newline at the end of the file. file1.config "CONFIG_1=y" file2.config "CONFIG_2=y" ./scripts/kconfig/merge_config.sh -m .config file1.config file2.config This will generate a .config looking like this. cat .config ... CONFIG_1=yCONFIG_2=y" Making sure so we add a newline at the end of every config file that is passed into the script. Signed-off-by: Anders Roxell <anders.roxell@linaro.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-29rust: work around `bindgen` 0.69.0 issueMiguel Ojeda
[ Upstream commit 9e98db17837093cb0f4dcfcc3524739d93249c45 ] `bindgen` 0.69.0 contains a bug: `--version` does not work without providing a header [1]: error: the following required arguments were not provided: <HEADER> Usage: bindgen <FLAGS> <OPTIONS> <HEADER> -- <CLANG_ARGS>... Thus, in preparation for supporting several `bindgen` versions, work around the issue by passing a dummy argument. Include a comment so that we can remove the workaround in the future. Link: https://github.com/rust-lang/rust-bindgen/pull/2678 [1] Reviewed-by: Finn Behrens <me@kloenk.dev> Tested-by: Benno Lossin <benno.lossin@proton.me> Tested-by: Andreas Hindborg <a.hindborg@samsung.com> Link: https://lore.kernel.org/r/20240709160615.998336-9-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Stable-dep-of: 5ce86c6c8613 ("rust: suppress error messages from CONFIG_{RUSTC,BINDGEN}_VERSION_TEXT") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03kbuild: avoid build error when single DTB is turned into composite DTBMasahiro Yamada
[ Upstream commit 712aba5543b88996bc4682086471076fbf048927 ] As commit afa974b77128 ("kbuild: add real-prereqs shorthand for $(filter-out FORCE,$^)") explained, $(real-prereqs) is not just a list of objects when linking a multi-object module. If a single-object module is turned into a multi-object module, $^ (and therefore $(real-prereqs) as well) contains header files recorded in the *.cmd file. Such headers must be filtered out. Now that a DTB can be built either from a single source or multiple source files, the same issue can occur. Consider the following scenario: First, foo.dtb is implemented as a single-blob device tree. The code looks something like this: [Sample Code 1] Makefile: dtb-y += foo.dtb foo.dts: #include <dt-bindings/gpio/gpio.h> /dts-v1/; / { }; When it is compiled, .foo.dtb.cmd records that foo.dtb depends on scripts/dtc/include-prefixes/dt-bindings/gpio/gpio.h. Later, foo.dtb is split into a base and an overlay. The code looks something like this: [Sample Code 2] Makefile: dtb-y += foo.dtb foo-dtbs := foo-base.dtb foo-addon.dtbo foo-base.dts: #include <dt-bindings/gpio/gpio.h> /dts-v1/; / { }; foo-addon.dtso: /dts-v1/; /plugin/; / { }; If you rebuild foo.dtb without 'make clean', you will get this error: Overlay 'scripts/dtc/include-prefixes/dt-bindings/gpio/gpio.h' is incomplete $(real-prereqs) contains not only foo-base.dtb and foo-addon.dtbo but also scripts/dtc/include-prefixes/dt-bindings/gpio/gpio.h, which is passed to scripts/dtc/fdtoverlay. Fixes: 15d16d6dadf6 ("kbuild: Add generic rule to apply fdtoverlay") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03kbuild: Fix '-S -c' in x86 stack protector scriptsNathan Chancellor
commit 3415b10a03945b0da4a635e146750dfe5ce0f448 upstream. After a recent change in clang to stop consuming all instances of '-S' and '-c' [1], the stack protector scripts break due to the kernel's use of -Werror=unused-command-line-argument to catch cases where flags are not being properly consumed by the compiler driver: $ echo | clang -o - -x c - -S -c -Werror=unused-command-line-argument clang: error: argument unused during compilation: '-c' [-Werror,-Wunused-command-line-argument] This results in CONFIG_STACKPROTECTOR getting disabled because CONFIG_CC_HAS_SANE_STACKPROTECTOR is no longer set. '-c' and '-S' both instruct the compiler to stop at different stages of the pipeline ('-S' after compiling, '-c' after assembling), so having them present together in the same command makes little sense. In this case, the test wants to stop before assembling because it is looking at the textual assembly output of the compiler for either '%fs' or '%gs', so remove '-c' from the list of arguments to resolve the error. All versions of GCC continue to work after this change, along with versions of clang that do or do not contain the change mentioned above. Cc: stable@vger.kernel.org Fixes: 4f7fd4d7a791 ("[PATCH] Add the -fstack-protector option to the CFLAGS") Fixes: 60a5317ff0f4 ("x86: implement x86_32 stack protector") Link: https://github.com/llvm/llvm-project/commit/6461e537815f7fa68cef06842505353cf5600e9c [1] Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-03x86/kconfig: Add as-instr64 macro to properly evaluate AS_WRUSSMasahiro Yamada
[ Upstream commit 469169803d52a5d8f0dc781090638e851a7d22b1 ] Some instructions are only available on the 64-bit architecture. Bi-arch compilers that default to -m32 need the explicit -m64 option to evaluate them properly. Fixes: 18e66b695e78 ("x86/shstk: Add Kconfig option for shadow stack") Closes: https://lore.kernel.org/all/20240612-as-instr-opt-wrussq-v2-1-bd950f7eead7@gmail.com/ Reported-by: Dmitry Safonov <0x7f454c46@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Tested-by: Dmitry Safonov <0x7f454c46@gmail.com> Link: https://lore.kernel.org/r/20240612050257.3670768-1-masahiroy@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-07-25kconfig: remove wrong expr_trans_bool()Masahiro Yamada
[ Upstream commit 77a92660d8fe8d29503fae768d9f5eb529c88b36 ] expr_trans_bool() performs an incorrect transformation. [Test Code] config MODULES def_bool y modules config A def_bool y select C if B != n config B def_tristate m config C tristate [Result] CONFIG_MODULES=y CONFIG_A=y CONFIG_B=m CONFIG_C=m This output is incorrect because CONFIG_C=y is expected. Documentation/kbuild/kconfig-language.rst clearly explains the function of the '!=' operator: If the values of both symbols are equal, it returns 'n', otherwise 'y'. Therefore, the statement: select C if B != n should be equivalent to: select C if y Or, more simply: select C Hence, the symbol C should be selected by the value of A, which is 'y'. However, expr_trans_bool() wrongly transforms it to: select C if B Therefore, the symbol C is selected by (A && B), which is 'm'. The comment block of expr_trans_bool() correctly explains its intention: * bool FOO!=n => FOO ^^^^ If FOO is bool, FOO!=n can be simplified into FOO. This is correct. However, the actual code performs this transformation when FOO is tristate: if (e->left.sym->type == S_TRISTATE) { ^^^^^^^^^^ While it can be fixed to S_BOOLEAN, there is no point in doing so because expr_tranform() already transforms FOO!=n to FOO when FOO is bool. (see the "case E_UNEQUAL" part) expr_trans_bool() is wrong and unnecessary. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-07-25kconfig: gconf: give a proper initial state to the Save buttonMasahiro Yamada
[ Upstream commit 46edf4372e336ef3a61c3126e49518099d2e2e6d ] Currently, the initial state of the "Save" button is always active. If none of the CONFIG options are changed while loading the .config file, the "Save" button should be greyed out. This can be fixed by calling conf_read() after widget initialization. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-07-18kbuild: Make ld-version.sh more robust against version string changesNathan Chancellor
[ Upstream commit 9852f47ac7c993990317570ff125e30ad901e213 ] After [1] in upstream LLVM, ld.lld's version output became slightly different when the cmake configuration option LLVM_APPEND_VC_REV is disabled. Before: Debian LLD 19.0.0 (compatible with GNU linkers) After: Debian LLD 19.0.0, compatible with GNU linkers This results in ld-version.sh failing with scripts/ld-version.sh: 18: arithmetic expression: expecting EOF: "10000 * 19 + 100 * 0 + 0," because the trailing comma is included in the patch level part of the expression. While [1] has been partially reverted in [2] to avoid this breakage (as it impacts the configuration stage and it is present in all LTS branches), it would be good to make ld-version.sh more robust against such miniscule changes like this one. Use POSIX shell parameter expansion [3] to remove the largest suffix after just numbers and periods, replacing of the current removal of everything after a hyphen. ld-version.sh continues to work for a number of distributions (Arch Linux, Debian, and Fedora) and the kernel.org toolchains and no longer errors on a version of ld.lld with [1]. Fixes: 02aff8592204 ("kbuild: check the minimum linker version in Kconfig") Link: https://github.com/llvm/llvm-project/commit/0f9fbbb63cfcd2069441aa2ebef622c9716f8dbb [1] Link: https://github.com/llvm/llvm-project/commit/649cdfc4b6781a350dfc87d9b2a4b5a4c3395909 [2] Link: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html [3] Suggested-by: Fangrui Song <maskray@google.com> Reviewed-by: Fangrui Song <maskray@google.com> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-07-11kbuild: fix short log for AS in link-vmlinux.shMasahiro Yamada
[ Upstream commit 3430f65d6130ccbc86f0ff45642eeb9e2032a600 ] In convention, short logs print the output file, not the input file. Let's change the suffix for 'AS' since it assembles *.S into *.o. [Before] LD .tmp_vmlinux.kallsyms1 NM .tmp_vmlinux.kallsyms1.syms KSYMS .tmp_vmlinux.kallsyms1.S AS .tmp_vmlinux.kallsyms1.S LD .tmp_vmlinux.kallsyms2 NM .tmp_vmlinux.kallsyms2.syms KSYMS .tmp_vmlinux.kallsyms2.S AS .tmp_vmlinux.kallsyms2.S LD vmlinux [After] LD .tmp_vmlinux.kallsyms1 NM .tmp_vmlinux.kallsyms1.syms KSYMS .tmp_vmlinux.kallsyms1.S AS .tmp_vmlinux.kallsyms1.o LD .tmp_vmlinux.kallsyms2 NM .tmp_vmlinux.kallsyms2.syms KSYMS .tmp_vmlinux.kallsyms2.S AS .tmp_vmlinux.kallsyms2.o LD vmlinux Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-07-05kbuild: Install dtb files as 0644 in Makefile.dtbinstDragan Simic
commit 9cc5f3bf63aa98bd7cc7ce8a8599077fde13283e upstream. The compiled dtb files aren't executable, so install them with 0644 as their permission mode, instead of defaulting to 0755 for the permission mode and installing them with the executable bits set. Some Linux distributions, including Debian, [1][2][3] already include fixes in their kernel package build recipes to change the dtb file permissions to 0644 in their kernel packages. These changes, when additionally propagated into the long-term kernel versions, will allow such distributions to remove their downstream fixes. [1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/642 [2] https://salsa.debian.org/kernel-team/linux/-/merge_requests/749 [3] https://salsa.debian.org/kernel-team/linux/-/blob/debian/6.8.12-1/debian/rules.real#L193 Cc: Diederik de Haas <didi.debian@cknow.org> Cc: <stable@vger.kernel.org> Fixes: aefd80307a05 ("kbuild: refactor Makefile.dtbinst more") Signed-off-by: Dragan Simic <dsimic@manjaro.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-05kbuild: Fix build target deb-pkg: ln: failed to create hard linkThayne Harbaugh
[ Upstream commit c61566538968ffb040acc411246fd7ad38c7e8c9 ] The make deb-pkg target calls debian-orig which attempts to either hard link the source .tar to the build-output location or copy the source .tar to the build-output location. The test to determine whether to ln or cp is incorrectly expanded by Make and consequently always attempts to ln the source .tar. This fix corrects the escaping of '$' so that the test is expanded by the shell rather than by Make and appropriately selects between ln and cp. Fixes: b44aa8c96e9e ("kbuild: deb-pkg: make .orig tarball a hard link if possible") Signed-off-by: Thayne Harbaugh <thayne@mastodonlabs.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-27locking/atomic: scripts: fix ${atomic}_sub_and_test() kerneldocCarlos Llamas
commit f92a59f6d12e31ead999fee9585471b95a8ae8a3 upstream. For ${atomic}_sub_and_test() the @i parameter is the value to subtract, not add. Fix the typo in the kerneldoc template and generate the headers with this update. Fixes: ad8110706f38 ("locking/atomic: scripts: generate kerneldoc comments") Suggested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Carlos Llamas <cmllamas@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20240515133844.3502360-1-cmllamas@google.com [cmllamas: generate headers with gen-atomics.sh] Signed-off-by: Carlos Llamas <cmllamas@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-21modpost: do not warn about missing MODULE_DESCRIPTION() for vmlinux.oMasahiro Yamada
[ Upstream commit 9185afeac2a3dcce8300a5684291a43c2838cfd6 ] Building with W=1 incorrectly emits the following warning: WARNING: modpost: missing MODULE_DESCRIPTION() in vmlinux.o This check should apply only to modules. Fixes: 1fffe7a34c89 ("script: modpost: emit a warning when the description is missing") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12kconfig: fix comparison to constant symbols, 'm', 'n'Masahiro Yamada
[ Upstream commit aabdc960a283ba78086b0bf66ee74326f49e218e ] Currently, comparisons to 'm' or 'n' result in incorrect output. [Test Code] config MODULES def_bool y modules config A def_tristate m config B def_bool A > n CONFIG_B is unset, while CONFIG_B=y is expected. The reason for the issue is because Kconfig compares the tristate values as strings. Currently, the .type fields in the constant symbol definitions, symbol_{yes,mod,no} are unspecified, i.e., S_UNKNOWN. When expr_calc_value() evaluates 'A > n', it checks the types of 'A' and 'n' to determine how to compare them. The left-hand side, 'A', is a tristate symbol with a value of 'm', which corresponds to a numeric value of 1. (Internally, 'y', 'm', and 'n' are represented as 2, 1, and 0, respectively.) The right-hand side, 'n', has an unknown type, so it is treated as the string "n" during the comparison. expr_calc_value() compares two values numerically only when both can have numeric values. Otherwise, they are compared as strings. symbol numeric value ASCII code ------------------------------------- y 2 0x79 m 1 0x6d n 0 0x6e 'm' is greater than 'n' if compared numerically (since 1 is greater than 0), but smaller than 'n' if compared as strings (since the ASCII code 0x6d is smaller than 0x6e). Specifying .type=S_TRISTATE for symbol_{yes,mod,no} fixes the above test code. Doing so, however, would cause a regression to the following test code. [Test Code 2] config MODULES def_bool n modules config A def_tristate n config B def_bool A = m You would get CONFIG_B=y, while CONFIG_B should not be set. The reason is because sym_get_string_value() turns 'm' into 'n' when the module feature is disabled. Consequently, expr_calc_value() evaluates 'A = n' instead of 'A = m'. This oddity has been hidden because the type of 'm' was previously S_UNKNOWN instead of S_TRISTATE. sym_get_string_value() should not tweak the string because the tristate value has already been correctly calculated. There is no reason to return the string "n" where its tristate value is mod. Fixes: 31847b67bec0 ("kconfig: allow use of relations other than (in)equality") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.46.0) at 2026-01-05 07:15:11 +0000