summaryrefslogtreecommitdiff
path: root/scripts
AgeCommit message (Collapse)Author
2026-01-31checkpatch: add an invalid patch separator testJoe Perches
Some versions of tools that apply patches incorrectly allow lines that start with 3 dashes and have additional content on the same line. Checkpatch will now emit an ERROR on these lines and optionally convert those lines from dashes to equals with --fix. Link: https://lkml.kernel.org/r/6ec1ed08328340db42655287afd5fa4067316b11.camel@perches.com Signed-off-by: Joe Perches <joe@perches.com> Suggested-by: Ian Rogers <irogers@google.com> Cc: Andy Whitcroft <apw@canonical.com> Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> Cc: Kuan-Wei Chiu <visitorckw@gmail.com> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com> Cc: Namhyung kim <namhyung@kernel.org> Cc: Stehen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-31Merge tag 'kbuild-fixes-6.19-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux Pull Kbuild fixes from Nicolas Schier: - Generate rpm-pkg debuginfo package manually, allowing signed kernel modules in rpm package, again - Fix permissions of modules.builtin.modinfo - Do not run kernel-doc when building external modules * tag 'kbuild-fixes-6.19-3' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux: kbuild: Do not run kernel-doc when building external modules kbuild: Fix permissions of modules.builtin.modinfo kbuild: rpm-pkg: Generate debuginfo package manually
2026-01-31kbuild: Do not run kernel-doc when building external modulesNathan Chancellor
After commit 778b8ebe5192 ("docs: Move the python libraries to tools/lib/python"), building an external module with any value of W= against the output of install-extmod-build fails with: $ make -C /usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build M=$PWD W=1 make: Entering directory '/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build' make[1]: Entering directory '...' CC [M] ... Traceback (most recent call last): File "/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build/scripts/kernel-doc.py", line 339, in <module> main() ~~~~^^ File "/usr/lib/modules/6.19.0-rc7-00108-g4d310797262f/build/scripts/kernel-doc.py", line 295, in main from kdoc.kdoc_files import KernelFiles # pylint: disable=C0415 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ModuleNotFoundError: No module named 'kdoc' scripts/lib was included in the build directory from find_in_scripts but after the move to tools/lib/python, it is no longer included, breaking kernel-doc.py. Commit eba6ffd126cd ("docs: kdoc: move kernel-doc to tools/docs") breaks this even further by moving kernel-doc outside of scripts as well, so it cannot be found when called by cmd_checkdoc. $ make -C /usr/lib/modules/6.19.0-rc7-next-20260130/build M=$PWD W=1 make: Entering directory '/usr/lib/modules/6.19.0-rc7-next-20260130/build' make[1]: Entering directory '...' CC [M] ... python3: can't open file '/usr/lib/modules/6.19.0-rc7-next-20260130/build/tools/docs/kernel-doc': [Errno 2] No such file or directory While kernel-doc could be useful for external modules, it is more useful for in-tree documentation that will be build and included in htmldocs. Rather than including it in install-extmod-build, just skip running kernel-doc for the external module build. Cc: stable@vger.kernel.org Fixes: 778b8ebe5192 ("docs: Move the python libraries to tools/lib/python") Reported-by: Rong Zhang <i@rong.moe> Closes: https://lore.kernel.org/20260129175321.415295-1-i@rong.moe/ Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260130-kbuild-skip-kernel-doc-extmod-v1-1-58443d60131a@kernel.org Reviewed-by: Nicolas Schier <nsc@kernel.org> Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-01-30Merge tag 'rust-fixes-6.19' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux Pull Rust fixes from Miguel Ojeda: "Toolchain and infrastructure: - Trigger rebuilds of the newly added 'proc-macro2' crate (and its dependencies) when the Rust compiler version changes - Fix error in '.rsi' targets (macro expanding single targets) under 'O=' pointing to an external (not subdir) folder - Fix off-by-one line number in 'rustdoc' KUnit tests - Add '-fdiagnostics-show-context' to GCC flags skipped by 'bindgen' - Clean objtool warning by adding one more 'noreturn' function - Clean 'libpin_init_internal.{so,dylib}' in 'mrproper' 'kernel' crate: - Fix build error when using expressions in formatting arguments - Mark 'num::Bounded::__new()' as unsafe and clean documentation accordingly - Always inline functions using 'build_assert' with arguments - Fix 'rusttest' build error providing the right 'isize_atomic_repr' type for the host 'macros' crate: - Fix 'rusttest' build error by ignoring example rust-analyzer: - Remove assertion that was not true for distributions like NixOS - Add missing dependency edges and fix editions for 'quote' and sysroot crates to provide correct IDE support DRM Tyr: - Fix build error by adding missing dependency on 'CONFIG_COMMON_CLK' Plus clean a few typos in docs and comments" * tag 'rust-fixes-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: (28 commits) rust: num: bounded: clean __new documentation and comments scripts: generate_rust_analyzer: fix resolution of #[pin_data] macros drm/tyr: depend on `COMMON_CLK` to fix build error rust: sync: atomic: Provide stub for `rusttest` 32-bit hosts kbuild: rust: clean libpin_init_internal in mrproper rust: proc-macro2: rebuild if the version text changes rust: num: bounded: add missing comment for always inlined function rust: sync: refcount: always inline functions using build_assert with arguments rust: bits: always inline functions using build_assert with arguments scripts: generate_rust_analyzer: compile sysroot with correct edition scripts: generate_rust_analyzer: compile quote with correct edition scripts: generate_rust_analyzer: quote: treat `core` and `std` as dependencies scripts: generate_rust_analyzer: syn: treat `std` as a dependency scripts: generate_rust_analyzer: remove sysroot assertion rust: kbuild: give `--config-path` to `rustfmt` in `.rsi` target scripts: generate_rust_analyzer: Add pin_init_internal deps scripts: generate_rust_analyzer: Add pin_init -> compiler_builtins dep scripts: generate_rust_analyzer: Add compiler_builtins -> core dep rust: macros: ignore example with module parameters rust: num: bounded: mark __new as unsafe ...
2026-01-30scripts: headers_install.sh: Remove config leak ignore machineryThomas Weißschuh
There are no entries left to ignore and none should be added again. Remove the now unused logic. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-01-30x86/uapi: Stop leaking kconfig references to userspaceThomas Weißschuh
UAPI headers are not supposed to leak references to kconfig symbols. These won't be set when building userspace. Hide the kconfig reference behind 'if defined(__KERNEL__)', so it will be stripped by headers_install.sh. The result for userspace will be the same, but the exceptions in headers_install.sh can also be removed. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-01-30nios2: uapi: Remove custom asm/swab.h from UAPIThomas Weißschuh
UAPI headers are not supposed to leak references to kconfig symbols. They are undefined there in any case. As all actual definitions of this header are guarded behind a kconfig symbol, for userspace the header is always identical to its asm-generic variant. Make the custom UAPI header a kernel-internal one, so the leaks of kconfig symbols are fixed and userspace will instead use asm-generic/swab.h directly. Suggested-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/lkml/93c55086-931a-4282-a94c-de4954047fa9@app.fastmail.com/ Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-01-30ARM: uapi: Drop PSR_ENDSTATEThomas Weißschuh
The symbol PSR_ENDSTATE is pointless for userspace. Drop it from the UAPI headers and instead inline it into the only two callers. As as side-effect, remove a leak of an internal kconfig symbol through the UAPI headers. Suggested-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/lkml/d2ad12f2-3d65-4bef-890c-65d78a33d790@app.fastmail.com/ Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-01-30ARC: Always use SWAPE instructions for __arch_swab32()Thomas Weißschuh
Since commit 67a697e7576 ("ARC: retire ARC750 support") all supported CPUs have the 'swape' instruction. Always use the implementation of __arch_swabe() which uses 'swape'. ARCH_USE_BUILTIN_BSWAP can not be used as that results on libcalls on -mcpu=arc700. As as side-effect, remove a leak of an internal kconfig symbol through the UAPI headers. Suggested-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/lkml/0ae2688a-5a22-405b-adaf-9b5ad712b245@app.fastmail.com/ Suggested-by: Vineet Gupta <vgupta@kernel.org> Link: https://lore.kernel.org/lkml/a033a402-e3c5-4982-9fff-b6a4c55817ae@kernel.org/ Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-01-29kbuild: dummy-tools: Add python3Michal Suchanek
DRM_MSM_VALIDATE_XML depends on a python feature. Add a dummy python interpreter to make it possible to configure this option with dummy tools. Fixes: b587f413ca47 ("drm/msm/gen_header: allow skipping the validation") Signed-off-by: Michal Suchanek <msuchanek@suse.de> Acked-by: Rob Clark <robin.clark@oss.qualcomm.com> Link: https://patch.msgid.link/20260121105801.1827-1-msuchanek@suse.de [nathan: Remove empty shell comment line] Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-01-29livepatch/klp-build: Require Clang assembler >= 20Josh Poimboeuf
Some special sections specify their ELF section entsize, for example: .pushsection section, "M", @progbits, 8 The entsize (8 in this example) is needed by objtool klp-diff for extracting individual entries. Clang assembler versions older than 20 silently ignore the above construct and set entsize to 0, resulting in the following error: .discard.annotate_data: missing special section entsize or annotations Add a klp-build check to prevent the use of Clang assembler versions prior to 20. Fixes: 24ebfcd65a87 ("livepatch/klp-build: Introduce klp-build script for generating livepatch modules") Reported-by: Song Liu <song@kernel.org> Acked-by: Song Liu <song@kernel.org> Link: https://patch.msgid.link/957fd52e375d0e2cfa3ac729160da995084a7f5e.1769562556.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
2026-01-28checkpatch: special-case cacheline group macrosMichael S. Tsirkin
Currently, cacheline group macros trigger checkpatch warnings. For example: $ ./scripts/checkpatch.pl -g ba7e025a6c84aed012421468d83639e5dae982b0 WARNING: Missing a blank line after declarations #58: FILE: drivers/gpio/gpio-virtio.c:32: + struct virtio_gpio_response res; + __dma_from_device_group_end(); $ ./scripts/checkpatch.pl -g 5d4cc87414c5d11345c4b11d61377d351b5c28a2 WARNING: Missing a blank line after declarations #267: FILE: include/net/sock.h:431: + int sk_rcvlowat; + __cacheline_group_end(sock_read_rx); But these are not actually statements - the following macros all expand to zero-length fields: __cacheline_group_begin() __cacheline_group_end() __cacheline_group_begin_aligned() __cacheline_group_end_aligned() __dma_from_device_group_begin() __dma_from_device_group_end() Add them to $declaration_macros so checkpatch recognizes this fact. Message-ID: <b345bb7e2d4e23672e3e5d1b283754dc11c7d8cd.1767647872.git.mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2026-01-28kbuild: Fix permissions of modules.builtin.modinfoEthan Zuo
Currently, modules.builtin.modinfo is created with executable permissions (0755). This is because after commit 39cfd5b12160 ("kbuild: extract modules.builtin.modinfo from vmlinux.unstripped"), modules.builtin.modinfo is extracted from vmlinux.unstripped using objcopy. When extracting sections, objcopy inherits attributes from the source ELF file. Since modules.builtin.modinfo is a data file and not an executable, it should have regular file permissions (0644). The executable bit can trigger warnings in Debian's Lintian tool. Explicitly remove the executable bit after generation. Fixes: 39cfd5b12160 ("kbuild: extract modules.builtin.modinfo from vmlinux.unstripped") Signed-off-by: Ethan Zuo <yuxuan.zuo@outlook.com> Link: https://patch.msgid.link/SY0P300MB0609F6916B24ADF65502940B9C91A@SY0P300MB0609.AUSP300.PROD.OUTLOOK.COM Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-01-28kbuild: rpm-pkg: Generate debuginfo package manuallyNathan Chancellor
Commit a7c699d090a1 ("kbuild: rpm-pkg: build a debuginfo RPM") adjusted the __spec_install_post macro to include __os_install_post, which runs brp-strip. This ends up stripping module signatures, breaking loading modules with lockdown enabled. Undo most of the changes of the aforementioned debuginfo patch and mirror commit 16c36f8864e3 ("kbuild: deb-pkg: use build ID instead of debug link for dbg package") in kernel.spec to generate a functionally equivalent debuginfo package while avoiding touching the modules after they have already been signed during modules_install. Fixes: a7c699d090a1 ("kbuild: rpm-pkg: build a debuginfo RPM") Reported-by: Holger Kiehl <Holger.Kiehl@dwd.de> Closes: https://lore.kernel.org/68c375f6-e07e-fec-434d-6a45a4f1390@praktifix.dwd.de/ Tested-by: Holger Kiehl <Holger.Kiehl@dwd.de> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20260121-fix-module-signing-binrpm-pkg-v1-1-8fc5832b6cbc@kernel.org Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-01-28Merge tag 'pin-init-v7.0' of https://github.com/Rust-for-Linux/linux into ↵Miguel Ojeda
rust-next Pull pin-init updates from Benno Lossin: "Added: - Implement 'InPlaceWrite' for '&'static mut MaybeUninit<T>'. This enables users to use external allocation mechanisms such as 'static_cell'. - Add Gary Guo as a Maintainer. Changed: - Rewrote all proc-macros ('[pin_]init!', '#[pin_data]', '#[pinned_drop]', 'derive([Maybe]Zeroable)'), using 'syn' with better diagnostics. - Support tuple structs in 'derive([Maybe]Zeroable)'. - Support attributes on fields in '[pin_]init!' (such as '#[cfg(...)]'). - Add a '#[default_error(<type>)]' attribute to '[pin_]init!' to override the default error (when no '? Error' is specified). - Support packed structs in '[pin_]init!' with '#[disable_initialized_field_access]'. Removed: - Remove 'try_[pin_]init!' in favor of merging their feature with '[pin_]init!'. Update the kernel's own 'try_[pin_]init!' macros to use the 'default_error' attribute. Fixed: - Correct 'T: Sized' bounds to 'T: ?Sized' in the generated 'PinnedDrop' check by '#[pin_data]'." * tag 'pin-init-v7.0' of https://github.com/Rust-for-Linux/linux: rust: pin-init: Implement `InPlaceWrite<T>` for `&'static mut MaybeUninit<T>` MAINTAINERS: add Gary Guo to pin-init rust: pin-init: internal: init: simplify Zeroable safety check rust: pin-init: internal: init: add escape hatch for referencing initialized fields rust: pin-init: internal: init: add support for attributes on initializer fields rust: init: use `#[default_error(err)]` for the initializer macros rust: pin-init: add `#[default_error(<type>)]` attribute to initializer macros rust: pin-init: rewrite the initializer macros using `syn` rust: pin-init: add `?Sized` bounds to traits in `#[pin_data]` macro rust: pin-init: rewrite `#[pin_data]` using `syn` rust: pin-init: rewrite the `#[pinned_drop]` attribute macro using `syn` rust: pin-init: rewrite `derive(Zeroable)` and `derive(MaybeZeroable)` using `syn` rust: pin-init: internal: add utility API for syn error handling rust: pin-init: add `syn` dependency and remove `proc-macro[2]` and `quote` workarounds rust: pin-init: allow the crate to refer to itself as `pin-init` in doc tests rust: pin-init: remove `try_` versions of the initializer macros
2026-01-27livepatch/klp-build: Fix klp-build vs CONFIG_MODULE_SRCVERSION_ALLJosh Poimboeuf
When building a patch to a single-file kernel module with CONFIG_MODULE_SRCVERSION_ALL enabled, the klp-build module link fails in modpost: Diffing objects drivers/md/raid0.o: changed function: raid0_run Building patch module: livepatch-0001-patch-raid0_run.ko drivers/md/raid0.c: No such file or directory ... The problem here is that klp-build copied drivers/md/.raid0.o.cmd to the module build directory, but it didn't also copy over the input source file listed in the .cmd file: source_drivers/md/raid0.o := drivers/md/raid0.c So modpost dies due to the missing .c file which is needed for calculating checksums for CONFIG_MODULE_SRCVERSION_ALL. Instead of copying the original .cmd file, just create an empty one. Modpost only requires that it exists. The original object's build dependencies are irrelevant for the frankenobjects used by klp-build. Fixes: 24ebfcd65a87 ("livepatch/klp-build: Introduce klp-build script for generating livepatch modules") Reported-by: Song Liu <song@kernel.org> Tested-by: Song Liu <song@kernel.org> Link: https://patch.msgid.link/c41b6629e02775e4c1015259aa36065b3fe2f0f3.1769471792.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
2026-01-26scripts: generate_rust_analyzer: fix resolution of #[pin_data] macrosSeungJong Ha
Currently, rust-analyzer fails to properly resolve structs annotated with `#[pin_data]`. This prevents IDE features like "Go to Definition" from working correctly for those structs. Add the missing configuration to `generate_rust_analyzer.py` to ensure the `pin-init` crate macros are handled correctly. Signed-off-by: SeungJong Ha <engineer.jjhama@gmail.com> Fixes: d7659acca7a3 ("rust: add pin-init crate build infrastructure") Cc: stable@vger.kernel.org Tested-by: Tamir Duberstein <tamird@kernel.org> Acked-by: Tamir Duberstein <tamird@kernel.org> Acked-by: Gary Guo <gary@garyguo.net> Reviewed-by: Jesung Yang <y.j3ms.n@gmail.com> Link: https://patch.msgid.link/20260123-fix-pin-init-crate-dependecies-v2-1-bb1c2500e54c@gmail.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-24Merge tag 'trace-v6.19-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracing fixes from Steven Rostedt: - Fix a crash with passing a stacktrace between synthetic events A synthetic event is an event that combines two events into a single event that can display fields from both events as well as the time delta that took place between the events. It can also pass a stacktrace from the first event so that it can be displayed by the synthetic event (this is useful to get a stacktrace of a task scheduling out when blocked and recording the time it was blocked for). A synthetic event can also connect an existing synthetic event to another event. An issue was found that if the first synthetic event had a stacktrace as one of its fields, and that stacktrace field was passed to the new synthetic event to be displayed, it would crash the kernel. This was due to the stacktrace not being saved as a stacktrace but was still marked as one. When the stacktrace was read, it would try to read an array but instead read the integer metadata of the stacktrace and dereferenced a bad value. Fix this by saving the stacktrace field as a stacktrace. - Fix possible overflow in cmp_mod_entry() compare function A binary search is used to find a module address and if the addresses are greater than 2GB apart it could lead to truncation and cause a bad search result. Use normal compares instead of a subtraction between addresses to calculate the compare value. - Fix output of entry arguments in function graph tracer Depending on the configurations enabled, the entry can be two different types that hold the argument array. The macro FGRAPH_ENTRY_ARGS() is used to find the correct arguments from the given type. One location was missed and still referenced the arguments directly via entry->args and could produce the wrong value depending on how the kernel was configured. - Fix memory leak in scripts/tracepoint-update build tool If the array fails to allocate, the memory for the values needs to be freed and was not. Free the allocated values if the array failed to allocate. * tag 'trace-v6.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: scripts/tracepoint-update: Fix memory leak in add_string() on failure function_graph: Fix args pointer mismatch in print_graph_retval() tracing: Avoid possible signed 64-bit truncation tracing: Fix crash on synthetic stacktrace field usage
2026-01-23scripts/tracepoint-update: Fix memory leak in add_string() on failureWeigang He
When realloc() fails in add_string(), the function returns -1 but leaves *vals pointing to the previously allocated memory. This can cause memory leaks in callers like make_trace_array() that return on error without freeing the partially built array. Fix this by freeing *vals and setting it to NULL when realloc() fails. This makes the error handling self-contained in add_string() so callers don't need to handle cleanup on failure. This bug is found by my static analysis tool and my code review. Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Fixes: e30f8e61e2518 ("tracing: Add a tracepoint verification check at build time") Link: https://patch.msgid.link/20260119114542.1714405-1-geoffreyhe2@gmail.com Signed-off-by: Weigang He <geoffreyhe2@gmail.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2026-01-22scripts: kconfig: merge_config.sh: warn on duplicate input filesMikko Rapeli
External scripts like yocto kernel scc may provide same input config fragment multiple times. This may be a bug since processing same fragments multiple times can be time consuming. Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org> Link: https://patch.msgid.link/20260122105751.2186609-3-mikko.rapeli@linaro.org Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-01-22scripts: kconfig: merge_config.sh: use awk in checks tooMikko Rapeli
Converting from shell/sed/grep loop to awk improves runtime checks of Yocto genericarm64 kernel config from 20 seconds to under 1 second. The checks catch this kind of issues: WARNING: CONFIG_BLK_DEV_DM differs: Requested value: CONFIG_BLK_DEV_DM=y Actual value: CONFIG_BLK_DEV_DM=m WARNING: CONFIG_SECURITY_NETWORK differs: Requested value: CONFIG_SECURITY_NETWORK=n Actual value: CONFIG_SECURITY_NETWORK=y WARNING: Value requested for CONFIG_ARM64_BTI_KERNEL not in final .config Requested value: CONFIG_ARM64_BTI_KERNEL=y Actual value: Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org> Link: https://patch.msgid.link/20260122105751.2186609-2-mikko.rapeli@linaro.org Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-01-22scripts: kconfig: merge_config.sh: refactor from shell/sed/grep to awkAnders Roxell
merge_config.sh shell/sed/grep loop scales poorly and is slow. With Yocto genericarm64 kernel and around 190 config fragments the script takes more than 20 minutes to run on a fast build machine. Re-implementation with awk does the same job in 10 seconds. Using awk since it is likely available in the build environments and using perl, python etc would introduce more complex runtime dependencies. awk is good enough and lot better than shell/sed/grep. Output stays the same but changed execution time means that parallel job output may be ordered differently. Signed-off-by: Anders Roxell <anders.roxell@linaro.org> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org> Link: https://patch.msgid.link/20260122105751.2186609-1-mikko.rapeli@linaro.org Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-01-22kallsyms: Get rid of kallsyms relative baseArd Biesheuvel
When the kallsyms relative base was introduced, per-CPU variable references on x86_64 SMP were implemented as offsets into the respective per-CPU region, rather than offsets relative to the location of the variable's template in the kernel image, which is how other architectures implement it. This required kallsyms to reason about the difference between the two, and the sign of the value in the kallsyms_offsets[] array was used to distinguish them. This meant that negative offsets were not permitted for ordinary variables, and so it was crucial that the relative base was chosen such that all offsets were positive numbers. This is no longer needed: instead, the offsets can simply be encoded as values in the range -/+ 2 GiB, which is precisely what PC32 relocations provide on most architectures. So it is possible to simplify the logic, and just use _text as the anchor directly, and let the linker calculate the final value based on the location of the entry itself. Some architectures (nios2, extensa) do not support place-relative relocations at all, but these are all 32-bit and non-relocatable, and so there is no need for place-relative relocations in the first place, and the actual symbol values can just be stored directly. This makes all entries in the kallsyms_offsets[] array visible as place-relative references in the ELF metadata, which will be important when implementing ELF-based fg-kaslr. Reviewed-by: Kees Cook <kees@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Link: https://patch.msgid.link/20260116093359.2442297-6-ardb+git@google.com Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-01-22scripts: add tool to run containerized buildsGuillaume Tucker
Add a 'scripts/container' tool written in Python to run any command in the source tree from within a container. This can typically be used to call 'make' with a compiler toolchain image to run reproducible builds but any arbitrary command can be run too. Only Docker and Podman are supported in this initial version. Add a new entry to MAINTAINERS accordingly. Link: https://lore.kernel.org/all/affb7aff-dc9b-4263-bbd4-a7965c19ac4e@gtucker.io/ Signed-off-by: Guillaume Tucker <gtucker@gtucker.io> Tested-by: Nicolas Schier <nsc@kernel.org> Acked-by: Nicolas Schier <nsc@kernel.org> Link: https://patch.msgid.link/9b8da20157e409e8fa3134d2101678779e157256.1769090419.git.gtucker@gtucker.io Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-01-22rseq: Implement sys_rseq_slice_yield()Thomas Gleixner
Provide a new syscall which has the only purpose to yield the CPU after the kernel granted a time slice extension. sched_yield() is not suitable for that because it unconditionally schedules, but the end of the time slice extension is not required to schedule when the task was already preempted. This also allows to have a strict check for termination to catch user space invoking random syscalls including sched_yield() from a time slice extension region. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20251215155708.929634896@linutronix.de
2026-01-21scripts/gen-btf.sh: Use CONFIG_SHELL for executionIhor Solodrai
According to the docs [1], kernel build scripts should be executed via CONFIG_SHELL, which is sh by default. Fixup gen-btf.sh to be runnable with sh, and use CONFIG_SHELL at every invocation site. See relevant discussion for context [2]. [1] https://docs.kernel.org/kbuild/makefiles.html#script-invocation [2] https://lore.kernel.org/bpf/CAADnVQ+dxmSNoJAGb6xV89ffUCKXe5CJXovXZt22nv5iYFV5mw@mail.gmail.com/ Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev> Tested-by: Gary Guo <gary@garyguo.net> Reported-by: Gary Guo <gary@garyguo.net> Suggested-by: Thomas Weißschuh <linux@weissschuh.net> Fixes: 522397d05e7d ("resolve_btfids: Change in-place update with raw binary output") Link: https://lore.kernel.org/r/20260121181617.820300-1-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-20docs: add a scripts/kernel-doc symbolic linkJonathan Corbet
Some folks evidently have muscle memory expecting kernel-doc to be under scripts/. Now that we have moved it to tools/docs, leave behind a symbolic link to reduce the global profanity count. Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2026-01-20docs: kdoc: move kernel-doc to tools/docsJonathan Corbet
kernel-doc is the last documentation-related tool still living outside of the tools/docs directory; the time has come to move it over. [mchehab: fixed kdoc lib location] Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <311d17e403524349940a8b12de6b5e91e554b1f4.1768823489.git.mchehab+huawei@kernel.org>
2026-01-20docs: kdoc: some fixes to kernel-doc commentsMauro Carvalho Chehab
There are some typos and English errors in the comments of kernel‑doc.py. Locate them with the help of an LLM (gpt‑oss 14B), executed locally with this prompt: review English grammar and syntax at the comments on the code below: <cat scripts/kernel-doc.py> While LLM worked fine for the task of doing an English grammar review for strings, being able to distinguish them from the actual code, it was not is perfect: some things required manual work to fix. - While here, replace: "/**" with: ``/**`` As, if we ever rename this script to kernel_doc.py and add it to Sphinx ext autodoc, we want to avoid this warning: scripts/kernel_doc.py:docstring of kernel_doc:10: WARNING: Inline strong start-string without end-string. [docutils] Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <ec08727f22ad35e6c58519c1f425f216f14b701c.1768823489.git.mchehab+huawei@kernel.org>
2026-01-20docs: kdoc: ensure that comments are using our coding styleMauro Carvalho Chehab
Along kernel-doc libs, we opted to have all comments starting/ending with a blank comment line. Use the same style here. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <50e430acd333a500719205e80ab3b2d297edcd7d.1768823489.git.mchehab+huawei@kernel.org>
2026-01-20docs: kdoc: avoid error_count overflowsMauro Carvalho Chehab
The glibc library limits the return code to 8 bits. We need to stick to this limit when using sys.exit(error_count). Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <233d1674db99ed8feb405a2f781de350f0fba0ac.1768823489.git.mchehab+huawei@kernel.org>
2026-01-19rust: kunit: replace `kernel::c_str!` with C-StringsTamir Duberstein
C-String literals were added in Rust 1.77. Replace instances of `kernel::c_str!` with C-String literals where possible. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Tamir Duberstein <tamird@gmail.com> Reviewed-by: David Gow <davidgow@google.com> Link: https://patch.msgid.link/20251222-cstr-kunit-v1-1-39d999672f35@gmail.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-18scripts: generate_rust_analyzer: compile sysroot with correct editionTamir Duberstein
Use `core_edition` for all sysroot crates rather than just core as all were updated to edition 2024 in Rust 1.87. Fixes: f4daa80d6be7 ("rust: compile libcore with edition 2024 for 1.87+") Signed-off-by: Tamir Duberstein <tamird@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260116-rust-analyzer-sysroot-v2-1-094aedc33208@kernel.org [ Added `>`s to make the quote a single block. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-18scripts: generate_rust_analyzer: compile quote with correct editionTamir Duberstein
Our copy of the quote crate uses edition 2018, thus generate the correct rust-analyzer configuration for it. Fixes: 88de91cc1ce7 ("rust: quote: enable support in kbuild") Signed-off-by: Tamir Duberstein <tamird@gmail.com> Reviewed-by: Jesung Yang <y.j3ms.n@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260115-rust-analyzer-quote-edition-v1-1-d492f880dde4@gmail.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-18scripts: generate_rust_analyzer: quote: treat `core` and `std` as dependenciesJesung Yang
Fix the `generate_rust_analyzer.py` script to ensure that the `rust-project.json` it produces includes `core` and `std` in the `deps` field for the `quote` crate. `quote` directly references items from both `core` and `std`, so rust-analyzer should treat them as dependencies to provide correct IDE support. For example, the `::quote::ToTokens` trait is implemented for `std::ffi::CString`. With `std` listed in the `deps` field, rust-analyzer can show the expected autocomplete for the `::quote::ToTokens` methods on `std::ffi::CString`. Verified the explicit uses of `core` and `std` using: grep -rnE 'core::|std::' rust/quote/ Fixes: 88de91cc1ce7 ("rust: quote: enable support in kbuild") Signed-off-by: Jesung Yang <y.j3ms.n@gmail.com> Reviewed-by: Tamir Duberstein <tamird@gmail.com> Link: https://patch.msgid.link/cef76fc1105481d219953c8552eb5eb07dac707a.1764062688.git.y.j3ms.n@gmail.com [ Reworded title. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-18scripts: generate_rust_analyzer: syn: treat `std` as a dependencyJesung Yang
Fix the `generate_rust_analyzer.py` script to ensure that the `rust-project.json` it produces includes `std` in the `deps` field for the `syn` crate. `syn` directly references items from `std`, so rust-analyzer should treat it as a dependency to provide correct IDE support. For example, `syn::Punctuated` contains fields of type `Vec<..>` and `Option<..>`, both of which come from the standard library prelude. With `std` listed in the `deps` field, rust-analyzer can infer the types of these fields instead of showing `{unknown}`. Verified the explicit uses of `std` using: grep -rn 'std::' rust/syn/ Fixes: 737401751ace ("rust: syn: enable support in kbuild") Signed-off-by: Jesung Yang <y.j3ms.n@gmail.com> Reviewed-by: Tamir Duberstein <tamird@gmail.com> Tested-by: Tamir Duberstein <tamird@gmail.com> Link: https://patch.msgid.link/6dbdf6e1c1639ae381ca9ab7041f84728ffa2267.1764062688.git.y.j3ms.n@gmail.com [ Reworded title. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-18scripts: generate_rust_analyzer: remove sysroot assertionOnur Özkan
With nixpkgs's rustc, rust-src component is not bundled with the compiler by default and is instead provided from a separate store path, so this assumption does not hold. The assertion assumes these paths are in the same location which causes `make LLVM=1 rust-analyzer` to fail on NixOS. Link: https://rust-for-linux.zulipchat.com/#narrow/stream/x/topic/x/near/565284250 Signed-off-by: Onur Özkan <work@onurozkan.dev> Reviewed-by: Gary Guo <gary@garyguo.net> Fixes: fe992163575b ("rust: Support latest version of `rust-analyzer`") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251224135343.32476-1-work@onurozkan.dev [ Reworded title. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-18rust: kbuild: give `--config-path` to `rustfmt` in `.rsi` targetMiguel Ojeda
`rustfmt` is configured via the `.rustfmt.toml` file in the source tree, and we apply `rustfmt` to the macro expanded sources generated by the `.rsi` target. However, under an `O=` pointing to an external folder (i.e. not just a subdir), `rustfmt` will not find the file when checking the parent folders. Since the edition is configured in this file, this can lead to errors when it encounters newer syntax, e.g. error: expected one of `!`, `.`, `::`, `;`, `?`, `where`, `{`, or an operator, found `"rust_minimal"` --> samples/rust/rust_minimal.rsi:29:49 | 28 | impl ::kernel::ModuleMetadata for RustMinimal { | - while parsing this item list starting here 29 | const NAME: &'static ::kernel::str::CStr = c"rust_minimal"; | ^^^^^^^^^^^^^^ expected one of 8 possible tokens 30 | } | - the item list ends here | = note: you may be trying to write a c-string literal = note: c-string literals require Rust 2021 or later = help: pass `--edition 2024` to `rustc` = note: for more on editions, read https://doc.rust-lang.org/edition-guide A workaround is to use `RUSTFMT=n`, which is documented in the `Makefile` help for cases where macro expanded source may happen to break `rustfmt` for other reasons, but this is not one of those cases. One solution would be to pass `--edition`, but we want `rustfmt` to use the entire configuration, even if currently we essentially use the default configuration. Thus explicitly give the path to the config file to `rustfmt` instead. Reported-by: Alice Ryhl <aliceryhl@google.com> Fixes: 2f7ab1267dc9 ("Kbuild: add Rust support") Cc: stable@vger.kernel.org Reviewed-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260115183832.46595-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-18compiler: Use __typeof_unqual__() for __unqual_scalar_typeof()Peter Zijlstra
The recent changes to get_unaligned() resulted in a new sparse warning: net/rds/ib_cm.c:96:35: sparse: sparse: incorrect type in argument 1 (different modifiers) @@ expected void * @@ got restricted __be64 const * @@ net/rds/ib_cm.c:96:35: sparse: expected void * net/rds/ib_cm.c:96:35: sparse: got restricted __be64 const * The updated get_unaligned_t() uses __unqual_scalar_typeof() to get an unqualified type. This works correctly for the compilers, but fails for sparse when the data type is __be64 (or any other __beNN variant). On sparse runs (C=[12]) __beNN types are annotated with __attribute__((bitwise)). That annotation allows sparse to detect incompatible operations on __beNN variables, but it also prevents sparse from evaluating the _Generic() in __unqual_scalar_typeof() and map __beNN to a unqualified scalar type, so it ends up with the default, i.e. the original qualified type of a 'const __beNN' pointer. That then ends up as the first pointer argument to builtin_memcpy(), which obviously causes the above sparse warnings. The sparse git tree supports typeof_unqual() now, which allows to use it instead of the _Generic() based __unqual_scalar_typeof(). With that sparse correctly evaluates the unqualified type and keeps the __beNN logic intact. The downside is that this requires a top of tree sparse build and an old sparse version will emit a metric ton of incomprehensible error messages before it dies with a segfault. Therefore implement a sanity check which validates that the checker is available and capable of handling typeof_unqual(). Emit a warning if not so the user can take informed action. [ tglx: Move the evaluation of USE_TYPEOF_UNQUAL to compiler_types.h so it is set before use and implement the sanity checker ] Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Acked-by: Ian Rogers <irogers@google.com> Link: https://patch.msgid.link/87ecnp2zh3.ffs@tglx Closes: https://lore.kernel.org/oe-kbuild-all/202601150001.sKSN644a-lkp@intel.com/
2026-01-17rust: pin-init: add `syn` dependency and remove `proc-macro[2]` and `quote` ↵Benno Lossin
workarounds `syn` makes parsing Rust from proc-macros a lot simpler. `pin-init` has not used `syn` up until now, because the we did not support it. That changed in commit 54e3eae85562 ("Merge patch series "`syn` support""), so we can finally utilize the added ergonomics of parsing proc-macro input with `syn`. Previously we only had the `proc-macro` library available, whereas the user-space version also used `proc-macro2` and `quote`. Now both are available, so remove the workarounds. Due to these changes, clippy emits warnings about unnecessary `.to_string()` as `proc-macro2` provides an additional `PartialEq` impl on `Ident`, so the warnings are fixed. [ Adjusted wording from upstream version and added build system changes for the kernel - Benno ] Co-developed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Tamir Duberstein <tamird@gmail.com> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Benno Lossin <lossin@kernel.org>
2026-01-14Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf after rc5Alexei Starovoitov
Cross-merge BPF and other fixes after downstream PR. No conflicts. Adjacent: Auto-merging MAINTAINERS Auto-merging Makefile Auto-merging kernel/bpf/verifier.c Auto-merging kernel/sched/ext.c Auto-merging mm/memcontrol.c Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-14checkpatch: Suggest kmalloc_obj family for sizeof allocationsKees Cook
To support shifting away from sized allocation towards typed allocations, suggest the kmalloc_obj family of macros when a sizeof() is present in the argument lists. Link: https://patch.msgid.link/20251203233036.3212363-2-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2026-01-14kbuild: Drop superfluous compiler option checksThomas Weißschuh
Many of the compiler option checks are not necessary anymore with the current supported versions of compilers (clang 15+, GCC 8.1+). Remove them. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://patch.msgid.link/20260113-kbuild-cc-option-v1-1-011314a0f7f1@weissschuh.net [nathan: Add minor note about currently supported compilers] Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-01-14scripts: generate_rust_analyzer: Add pin_init_internal depsTamir Duberstein
Commit d7659acca7a3 ("rust: add pin-init crate build infrastructure") did not add dependencies to `pin_init_internal`, resulting in broken navigation. Thus add them now. [ Tamir elaborates: "before this series, go-to-symbol from pin_init_internal to e.g. proc_macro::TokenStream doesn't work." - Miguel ] Signed-off-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Jesung Yang <y.j3ms.n@gmail.com> Acked-by: Benno Lossin <lossin@kernel.org> Fixes: d7659acca7a3 ("rust: add pin-init crate build infrastructure") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250723-rust-analyzer-pin-init-v1-3-3c6956173c78@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-14scripts: generate_rust_analyzer: Add pin_init -> compiler_builtins depTamir Duberstein
Add a dependency edge from `pin_init` to `compiler_builtins` to `scripts/generate_rust_analyzer.py` to match `rust/Makefile`. This has been incorrect since commit d7659acca7a3 ("rust: add pin-init crate build infrastructure"). Signed-off-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Jesung Yang <y.j3ms.n@gmail.com> Acked-by: Benno Lossin <lossin@kernel.org> Fixes: d7659acca7a3 ("rust: add pin-init crate build infrastructure") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250723-rust-analyzer-pin-init-v1-2-3c6956173c78@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-14scripts: generate_rust_analyzer: Add compiler_builtins -> core depTamir Duberstein
Add a dependency edge from `compiler_builtins` to `core` to `scripts/generate_rust_analyzer.py` to match `rust/Makefile`. This has been incorrect since commit 8c4555ccc55c ("scripts: add `generate_rust_analyzer.py`") Signed-off-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Jesung Yang <y.j3ms.n@gmail.com> Acked-by: Benno Lossin <lossin@kernel.org> Fixes: 8c4555ccc55c ("scripts: add `generate_rust_analyzer.py`") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250723-rust-analyzer-pin-init-v1-1-3c6956173c78@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-14kconfig: fix static linking of nconfArkadiusz Kozdra
When running make nconfig with a static linking host toolchain, the libraries are linked in an incorrect order, resulting in errors similar to the following: $ MAKEFLAGS='HOSTCC=cc\ -static' make nconfig /usr/bin/ld: /usr/lib64/gcc/x86_64-unknown-linux-gnu/14.2.1/../../../../lib64/libpanel.a(p_new.o): in function `new_panel': (.text+0x13): undefined reference to `_nc_panelhook_sp' /usr/bin/ld: (.text+0x6c): undefined reference to `_nc_panelhook_sp' Fixes: 1c5af5cf9308 ("kconfig: refactor ncurses package checks for building mconf and nconf") Signed-off-by: Arusekk <floss@arusekk.pl> Link: https://patch.msgid.link/20260110114808.22595-1-floss@arusekk.pl [nsc: Added comment about library order] Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-01-14kbuild: prefer ${NM} in check-function-names.shCarlos Llamas
The check-function-names.sh scripts invokes 'nm' directly and this can be problematic during cross-compilation when the toolchain is different from the system's default (e.g. LLVM=1). scripts/check-function-names.sh: nm: not found Let's prefer the ${NM} variable which is already set by kbuild. However, still fallback to plain 'nm' to ensure the script is still usable when called directly. Fixes: 93863f3f859a ("kbuild: Check for functions with ambiguous -ffunction-sections section names") Signed-off-by: Carlos Llamas <cmllamas@google.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20251218175824.3122690-1-cmllamas@google.com Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-01-12lib/crypto: tests: Add KUnit tests for NHEric Biggers
Add some simple KUnit tests for the nh() function. These replace the test coverage which will be lost by removing the nhpoly1305 crypto_shash. Note that the NH code also continues to be tested indirectly as well, via the tests for the "adiantum(xchacha12,aes)" crypto_skcipher. Link: https://lore.kernel.org/r/20251211011846.8179-3-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-01-11Merge tag 'libcrypto-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux Pull crypto library fixes from Eric Biggers: - A couple more fixes for the lib/crypto KUnit tests - Fix missing MMU protection for the AES S-box * tag 'libcrypto-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: lib/crypto: aes: Fix missing MMU protection for AES S-box MAINTAINERS: add test vector generation scripts to "CRYPTO LIBRARY" lib/crypto: tests: Fix syntax error for old python versions lib/crypto: tests: polyval_kunit: Increase iterations for preparekey in IRQs
generated by cgit v1.2.3 (git 2.0.4) at 2026-02-23 12:12:56 +0000