user/sven/linux.git/scripts, branch v6.1.56

kconfig: fix possible buffer overflow

2023-09-19T10:27:59Z

[ Upstream commit a3b7039bb2b22fcd2ad20d59c00ed4e606ce3754 ] Buffer 'new_argv' is accessed without bound check after accessing with bound check via 'new_argc' index. Fixes: e298f3b49def ("kconfig: add built-in function support") Co-developed-by: Ivanov Mikhail Signed-off-by: Konstantin Meskhidze Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

kbuild: rpm-pkg: define _arch conditionally

2023-09-19T10:27:58Z

[ Upstream commit 233046a2afd12a4f699305b92ee634eebf1e4f31 ] Commit 3089b2be0cce ("kbuild: rpm-pkg: fix build error when _arch is undefined") does not work as intended; _arch is always defined as $UTS_MACHINE. The intention was to define _arch to $UTS_MACHINE only when it is not defined. Fixes: 3089b2be0cce ("kbuild: rpm-pkg: fix build error when _arch is undefined") Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

kbuild: rust_is_available: fix confusion when a version appears in the path

2023-09-13T07:42:32Z

[ Upstream commit 9eb7e20e0c5cd069457845f965b3e8a7d736ecb7 ] `bindgen`'s output for `libclang`'s version check contains paths, which in turn may contain strings that look like version numbers [1][2]: .../6.1.0-dev/.../rust_is_available_bindgen_libclang.h:2:9: warning: clang version 11.1.0 [-W#pragma-messages], err: false which the script will pick up as the version instead of the latter. It is also the case that versions may appear after the actual version (e.g. distribution's version text), which was the reason behind `head` [3]: .../rust-is-available-bindgen-libclang.h:2:9: warning: clang version 13.0.0 (Fedora 13.0.0-3.fc35) [-W#pragma-messages], err: false Thus instead ask for a match after the `clang version` string. Reported-by: Jordan Isaacs Closes: https://github.com/Rust-for-Linux/linux/issues/942 [1] Reported-by: "Ethan D. Twardy" Closes: https://lore.kernel.org/rust-for-linux/20230528131802.6390-2-ethan.twardy@gmail.com/ [2] Reported-by: Tiago Lam Closes: https://github.com/Rust-for-Linux/linux/pull/789 [3] Fixes: 78521f3399ab ("scripts: add `rust_is_available.sh`") Reviewed-by: Martin Rodriguez Reboredo Reviewed-by: Ethan Twardy Tested-by: Ethan Twardy Reviewed-by: Nathan Chancellor Link: https://lore.kernel.org/r/20230616001631.463536-8-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin

kbuild: rust_is_available: add check for `bindgen` invocation

2023-09-13T07:42:32Z

[ Upstream commit 52cae7f28ed6c3992489f16bb355f5b623f0912e ] `scripts/rust_is_available.sh` calls `bindgen` with a special header in order to check whether the `libclang` version in use is suitable. However, the invocation itself may fail if, for instance, `bindgen` cannot locate `libclang`. This is fine for Kconfig (since the script will still fail and therefore disable Rust as it should), but it is pretty confusing for users of the `rustavailable` target given the error will be unrelated: ./scripts/rust_is_available.sh: 21: arithmetic expression: expecting primary: "100000 * + 100 * + " make: *** [Makefile:1816: rustavailable] Error 2 Instead, run the `bindgen` invocation independently in a previous step, saving its output and return code. If it fails, then show the user a proper error message. Otherwise, continue as usual with the saved output. Since the previous patch we show a reference to the docs, and the docs now explain how `bindgen` looks for `libclang`, thus the error message can leverage the documentation, avoiding duplication here (and making users aware of the setup guide in the documentation). Reported-by: Nick Desaulniers Link: https://lore.kernel.org/rust-for-linux/CAKwvOdm5JT4wbdQQYuW+RT07rCi6whGBM2iUAyg8A1CmLXG6Nw@mail.gmail.com/ Reported-by: François Valenduc Closes: https://github.com/Rust-for-Linux/linux/issues/934 Reported-by: Alexandru Radovici Closes: https://github.com/Rust-for-Linux/linux/pull/921 Reported-by: Matthew Leach Closes: https://lore.kernel.org/rust-for-linux/20230507084116.1099067-1-dev@mattleach.net/ Fixes: 78521f3399ab ("scripts: add `rust_is_available.sh`") Reviewed-by: Martin Rodriguez Reboredo Reviewed-by: Masahiro Yamada Reviewed-by: Nathan Chancellor Link: https://lore.kernel.org/r/20230616001631.463536-6-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin

kbuild: rust_is_available: fix version check when CC has multiple arguments

2023-09-13T07:42:32Z

[ Upstream commit dee3a6b819c96fc8b1907577f585fd66f5c0fefe ] rust_is_available.sh uses cc-version.sh to identify which C compiler is in use, as scripts/Kconfig.include does. cc-version.sh isn't designed to be able to handle multiple arguments in one variable, i.e. "ccache clang". Its invocation in rust_is_available.sh quotes "$CC", which makes $1 == "ccache clang" instead of the intended $1 == ccache & $2 == clang. cc-version.sh could also be changed to handle having "ccache clang" as one argument, but it only has the one consumer upstream, making it simpler to fix the caller here. Signed-off-by: Russell Currey Fixes: 78521f3399ab ("scripts: add `rust_is_available.sh`") Link: https://github.com/Rust-for-Linux/linux/pull/873 [ Reworded title prefix and reflow line to 75 columns. ] Reviewed-by: Martin Rodriguez Reboredo Reviewed-by: Nathan Chancellor Link: https://lore.kernel.org/r/20230616001631.463536-3-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin

kbuild: rust_is_available: remove -v option

2023-09-13T07:42:32Z

[ Upstream commit d824d2f98565e7c4cb1b862c230198fbe1a968be ] The -v option is passed when this script is invoked from Makefile, but not when invoked from Kconfig. As you can see in scripts/Kconfig.include, the 'success' macro suppresses stdout and stderr anyway, so this script does not need to be quiet. Signed-off-by: Masahiro Yamada Reviewed-by: Miguel Ojeda Tested-by: Miguel Ojeda Reviewed-by: Nathan Chancellor Link: https://lore.kernel.org/r/20230109061436.3146442-1-masahiroy@kernel.org [ Reworded prefix to match the others in the patch series. ] Reviewed-by: Martin Rodriguez Reboredo Link: https://lore.kernel.org/r/20230616001631.463536-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda Stable-dep-of: dee3a6b819c9 ("kbuild: rust_is_available: fix version check when CC has multiple arguments") Signed-off-by: Sasha Levin

gcc-plugins: Reorganize gimple includes for GCC 13

2023-08-16T16:27:20Z

commit e6a71160cc145e18ab45195abf89884112e02dfb upstream. The gimple-iterator.h header must be included before gimple-fold.h starting with GCC 13. Reorganize gimple headers to work for all GCC versions. Reported-by: Palmer Dabbelt Acked-by: Palmer Dabbelt Link: https://lore.kernel.org/all/20230113173033.4380-1-palmer@rivosinc.com/ Cc: linux-hardening@vger.kernel.org Signed-off-by: Kees Cook Cc: Naresh Kamboju Signed-off-by: Greg Kroah-Hartman

scripts/kallsyms: update the usage in the comment block

2023-07-27T06:50:50Z

commit 79549da691edd4874c19d99c578a134471817c47 upstream. Commit 010a0aad39fc ("kallsyms: Correctly sequence symbols when CONFIG_LTO_CLANG=y") added --lto-clang, and updated the usage() function, but not the comment. Update it in the same way. Signed-off-by: Masahiro Yamada Reviewed-by: Nick Desaulniers Signed-off-by: Greg Kroah-Hartman

scripts/kallsyms.c Make the comment up-to-date with current implementation

2023-07-27T06:50:50Z

commit adc40221bf676f3e722d135889a7b913b4162dc2 upstream. The comment in scripts/kallsyms.c describing the usage of scripts/kallsyms does not reflect the latest implementation. Fix the comment to be equivalent to what the usage() function prints. Signed-off-by: Yuma Ueda Reviewed-by: Miguel Ojeda Link: https://lore.kernel.org/r/20221118133631.4554-1-cyan@0x00a1e9.dev Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

kallsyms: add kallsyms_seqs_of_names to list of special symbols

2023-07-27T06:50:50Z

commit ced0f245ed951e2b8bd68f79c15238d7dd253662 upstream. My randconfig build setup ran into another kallsyms warning: Inconsistent kallsyms data Try make KALLSYMS_EXTRA_PASS=1 as a workaround After adding some debugging code to kallsyms.c, I saw that the recently added kallsyms_seqs_of_names symbol can sometimes cause the second stage table to be slightly longer than the first stage, which makes the build inconsistent. Add it to the exception table that contains all other kallsyms-generated symbols. Fixes: 60443c88f3a8 ("kallsyms: Improve the performance of kallsyms_lookup_name()") Signed-off-by: Arnd Bergmann Reviewed-by: Zhen Lei Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman