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

modpost: Fix processing of CRCs on 32-bit build machines

2023-04-06T10:10:53Z

commit fb27e70f6e408dee5d22b083e7a38a59e6118253 upstream. modpost now reads CRCs from .*.cmd files, parsing them using strtol(). This is inconsistent with its parsing of Module.symvers and with their definition as *unsigned* 32-bit values. strtol() clamps values to [LONG_MIN, LONG_MAX], and when building on a 32-bit system this changes all CRCs >= 0x80000000 to be 0x7fffffff. Change extract_crcs_for_object() to use strtoul() instead. Cc: stable@vger.kernel.org Fixes: f292d875d0dc ("modpost: extract symbol versions from *.cmd files") Signed-off-by: Ben Hutchings Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman

kconfig: Update config changed flag before calling callback

2023-03-22T12:33:52Z

[ Upstream commit ee06a3ef7e3cddb62b90ac40aa661d3c12f7cabc ] Prior to commit 5ee546594025 ("kconfig: change sym_change_count to a boolean flag"), the conf_updated flag was set to the new value *before* calling the callback. xconfig's save action depends on this behaviour, because xconfig calls conf_get_changed() directly from the callback and now sees the old value, thus never enabling the save button or the shortcut. Restore the previous behaviour. Fixes: 5ee546594025 ("kconfig: change sym_change_count to a boolean flag") Signed-off-by: Jurica Vukadin Acked-by: Randy Dunlap Tested-by: Randy Dunlap Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

scripts: handle BrokenPipeError for python scripts

2023-03-17T07:50:31Z

[ Upstream commit 87c7ee67deb7fce9951a5f9d80641138694aad17 ] In the follow-up of commit fb3041d61f68 ("kbuild: fix SIGPIPE error message for AR=gcc-ar and AR=llvm-ar"), Kees Cook pointed out that tools should _not_ catch their own SIGPIPEs [1] [2]. Based on his feedback, LLVM was fixed [3]. However, Python's default behavior is to show noisy bracktrace when SIGPIPE is sent. So, scripts written in Python are basically in the same situation as the buggy llvm tools. Example: $ make -s allnoconfig $ make -s allmodconfig $ scripts/diffconfig .config.old .config | head -n1 -ALIX n Traceback (most recent call last): File "/home/masahiro/linux/scripts/diffconfig", line 132, in main() File "/home/masahiro/linux/scripts/diffconfig", line 130, in main print_config("+", config, None, b[config]) File "/home/masahiro/linux/scripts/diffconfig", line 64, in print_config print("+%s %s" % (config, new_value)) BrokenPipeError: [Errno 32] Broken pipe Python documentation [4] notes how to make scripts die immediately and silently: """ Piping output of your program to tools like head(1) will cause a SIGPIPE signal to be sent to your process when the receiver of its standard output closes early. This results in an exception like BrokenPipeError: [Errno 32] Broken pipe. To handle this case, wrap your entry point to catch this exception as follows: import os import sys def main(): try: # simulate large output (your code replaces this loop) for x in range(10000): print("y") # flush output here to force SIGPIPE to be triggered # while inside this try block. sys.stdout.flush() except BrokenPipeError: # Python flushes standard streams on exit; redirect remaining output # to devnull to avoid another BrokenPipeError at shutdown devnull = os.open(os.devnull, os.O_WRONLY) os.dup2(devnull, sys.stdout.fileno()) sys.exit(1) # Python exits with error code 1 on EPIPE if __name__ == '__main__': main() Do not set SIGPIPE’s disposition to SIG_DFL in order to avoid BrokenPipeError. Doing that would cause your program to exit unexpectedly whenever any socket connection is interrupted while your program is still writing to it. """ Currently, tools/perf/scripts/python/intel-pt-events.py seems to be the only script that fixes the issue that way. tools/perf/scripts/python/compaction-times.py uses another approach signal.signal(signal.SIGPIPE, signal.SIG_DFL) but the Python documentation clearly says "Don't do it". I cannot fix all Python scripts since there are so many. I fixed some in the scripts/ directory. [1]: https://lore.kernel.org/all/202211161056.1B9611A@keescook/ [2]: https://github.com/llvm/llvm-project/issues/59037 [3]: https://github.com/llvm/llvm-project/commit/4787efa38066adb51e2c049499d25b3610c0877b [4]: https://docs.python.org/3/library/signal.html#note-on-sigpipe Signed-off-by: Masahiro Yamada Reviewed-by: Nick Desaulniers Reviewed-by: Nicolas Schier Signed-off-by: Sasha Levin

gcc-plugins: drop -std=gnu++11 to fix GCC 13 build

2023-03-10T08:33:51Z

[ Upstream commit 5a6b64adc18d9adfb497a529ff004d59b6df151f ] The latest GCC 13 snapshot (13.0.1 20230129) gives the following: ``` cc1: error: cannot load plugin ./scripts/gcc-plugins/randomize_layout_plugin.so :./scripts/gcc-plugins/randomize_layout_plugin.so: undefined symbol: tree_code_type ``` This ends up being because of https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=b0241ce6e37031 upstream in GCC which changes the visibility of some types used by the kernel's plugin infrastructure like tree_code_type. After discussion with the GCC folks, we found that the kernel needs to be building plugins with the same flags used to build GCC - and GCC defaults to gnu++17 right now. The minimum GCC version needed to build the kernel is GCC 5.1 and GCC 5.1 already defaults to gnu++14 anyway, so just drop the flag, as all GCCs that could be used to build GCC already default to an acceptable version which was >= the version we forced via flags until now. Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634 Signed-off-by: Sam James Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20230201230009.2252783-1-sam@gentoo.org Signed-off-by: Sasha Levin

builddeb: clean generated package content

2023-03-10T08:33:41Z

[ Upstream commit c9f9cf2560e40b62015c6c4a04be60f55ce5240e ] For each binary Debian package, a directory with the package name is created in the debian directory. Correct the generated file matches in the package's clean target, which were renamed without adjusting the target. Fixes: 1694e94e4f46 ("builddeb: match temporary directory name to the package name") Signed-off-by: Bastian Germann Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

scripts/tags.sh: fix incompatibility with PCRE2

2023-03-03T10:52:25Z

commit 6ec363fc6142226b9ab5a6528f65333d729d2b6b upstream. Starting with release 10.38 PCRE2 drops default support for using \K in lookaround patterns as described in [1]. Unfortunately, scripts/tags.sh relies on such functionality to collect all_compiled_soures() leading to the following error: $ make COMPILED_SOURCE=1 tags GEN tags grep: \K is not allowed in lookarounds (but see PCRE2_EXTRA_ALLOW_LOOKAROUND_BSK) The usage of \K for this pattern was introduced in commit 4f491bb6ea2a ("scripts/tags.sh: collect compiled source precisely") which speeds up the generation of tags significantly. In order to fix this issue without compromising the performance we can switch over to an equivalent sed expression. The same matching pattern is preserved here except \K is replaced with a backreference \1. [1] https://www.pcre.org/current/doc/html/pcre2syntax.html#SEC11 Cc: Greg Kroah-Hartman Cc: Cristian Ciocaltea Cc: Masahiro Yamada Cc: Jialu Xu Cc: Vipin Sharma Cc: stable@vger.kernel.org Fixes: 4f491bb6ea2a ("scripts/tags.sh: collect compiled source precisely") Signed-off-by: Carlos Llamas Link: https://lore.kernel.org/r/20230215183850.3353198-1-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman

arm64: remove special treatment for the link order of head.o

2023-02-25T10:25:42Z

commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream. In the previous discussion (see the Link tag), Ard pointed out that arm/arm64/kernel/head.o does not need any special treatment - the only piece that must appear right at the start of the binary image is the image header which is emitted into .head.text. The linker script does the right thing to do. The build system does not need to manipulate the link order of head.o. Link: https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=EuA@mail.gmail.com/ Suggested-by: Ard Biesheuvel Signed-off-by: Masahiro Yamada Reviewed-by: Nicolas Schier Link: https://lore.kernel.org/r/20221012233500.156764-1-masahiroy@kernel.org Signed-off-by: Will Deacon Signed-off-by: Tom Saeger Signed-off-by: Greg Kroah-Hartman

riscv: remove special treatment for the link order of head.o

2023-02-25T10:25:41Z

commit 2348e6bf44213c5f447ff698e43c089185241ed7 upstream. arch/riscv/kernel/head.o does not need any special treatment - the only requirement is the ".head.text" section must be placed before the normal ".text" section. The linker script does the right thing to do. The build system does not need to manipulate the link order of head.o. Signed-off-by: Jisheng Zhang Link: https://lore.kernel.org/r/20221018141200.1040-1-jszhang@kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Tom Saeger Signed-off-by: Greg Kroah-Hartman

kbuild: modinst: Fix build error when CONFIG_MODULE_SIG_KEY is a PKCS#11 URI

2023-02-09T10:28:11Z

[ Upstream commit 22e46f6480e83bcf49b6d5e6b66c81872c97a902 ] When CONFIG_MODULE_SIG_KEY is PKCS#11 URI (pkcs11:*), signing of modules fails: scripts/sign-file sha256 /.../linux/pkcs11:token=foo;object=bar;pin-value=1111 certs/signing_key.x509 /.../kernel/crypto/tcrypt.ko Usage: scripts/sign-file [-dp] [] scripts/sign-file -s [] First, we need to avoid adding the $(srctree)/ prefix to the URL. Second, since the kconfig string values no longer include quotes, we need to add them again when passing a PKCS#11 URI to sign-file. This avoids splitting by the shell if the URI contains semicolons. Fixes: 4db9c2e3d055 ("kbuild: stop using config_filename in scripts/Makefile.modsign") Fixes: 129ab0d2d9f3 ("kbuild: do not quote string values in include/config/auto.conf") Signed-off-by: Jan Luebbe Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

Fix up more non-executable files marked executable

2023-02-01T07:34:49Z

[ Upstream commit c96618275234ad03d44eafe9f8844305bb44fda4 ] Joe found another DT file that shouldn't be executable, and that frustrated me enough that I went hunting with this script: git ls-files -s | grep '^100755' | cut -f2 | xargs grep -L '^#!' and that found another file that shouldn't have been marked executable either, despite being in the scripts directory. Maybe these two are the last ones at least for now. But I'm sure we'll be back in a few years, fixing things up again. Fixes: 8c6789f4e2d4 ("ASoC: dt-bindings: Add Everest ES8326 audio CODEC") Fixes: 4d8e5cd233db ("locking/atomics: Fix scripts/atomic/ script permissions") Reported-by: Joe Perches Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin