aboutsummaryrefslogtreecommitdiff
path: root/scripts
AgeCommit message (Collapse)AuthorFilesLines
7 daysMerge tag 'objtool-urgent-2026-02-07' of ↵Linus Torvalds3-18/+15
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull objtool fixes from Ingo Molnar:: - Bump up the Clang minimum version requirements for livepatch builds, due to Clang assembler section handling bugs causing silent miscompilations - Strip livepatching symbol artifacts from non-livepatch modules - Fix livepatch build warnings when certain Clang LTO options are enabled - Fix livepatch build error when CONFIG_MEM_ALLOC_PROFILING_DEBUG=y * tag 'objtool-urgent-2026-02-07' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: objtool/klp: Fix unexported static call key access for manually built livepatch modules objtool/klp: Fix symbol correlation for orphaned local symbols livepatch: Free klp_{object,func}_ext data after initialization livepatch: Fix having __klp_objects relics in non-livepatch modules livepatch/klp-build: Require Clang assembler >= 20
9 dayslivepatch: Free klp_{object,func}_ext data after initializationPetr Pavlu2-3/+3
The klp_object_ext and klp_func_ext data, which are stored in the __klp_objects and __klp_funcs sections, respectively, are not needed after they are used to create the actual klp_object and klp_func instances. This operation is implemented by the init function in scripts/livepatch/init.c. Prefix the two sections with ".init" so they are freed after the module is initializated. Signed-off-by: Petr Pavlu <petr.pavlu@suse.com> Acked-by: Joe Lawrence <joe.lawrence@redhat.com> Acked-by: Miroslav Benes <mbenes@suse.cz> Reviewed-by: Aaron Tomlin <atomlin@atomlin.com> Link: https://patch.msgid.link/20260123102825.3521961-3-petr.pavlu@suse.com Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
9 dayslivepatch: Fix having __klp_objects relics in non-livepatch modulesPetr Pavlu2-17/+10
The linker script scripts/module.lds.S specifies that all input __klp_objects sections should be consolidated into an output section of the same name, and start/stop symbols should be created to enable scripts/livepatch/init.c to locate this data. This start/stop pattern is not ideal for modules because the symbols are created even if no __klp_objects input sections are present. Consequently, a dummy __klp_objects section also appears in the resulting module. This unnecessarily pollutes non-livepatch modules. Instead, since modules are relocatable files, the usual method for locating consolidated data in a module is to read its section table. This approach avoids the aforementioned problem. The klp_modinfo already stores a copy of the entire section table with the final addresses. Introduce a helper function that scripts/livepatch/init.c can call to obtain the location of the __klp_objects section from this data. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Signed-off-by: Petr Pavlu <petr.pavlu@suse.com> Acked-by: Joe Lawrence <joe.lawrence@redhat.com> Acked-by: Miroslav Benes <mbenes@suse.cz> Reviewed-by: Aaron Tomlin <atomlin@atomlin.com> Link: https://patch.msgid.link/20260123102825.3521961-2-petr.pavlu@suse.com Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
13 daysMerge tag 'objtool-urgent-2026-02-01' of ↵Linus Torvalds1-4/+4
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull objtool fixes from Ingo Molnar: - Fix a build error on ia32-x86_64 cross builds - Replace locally open coded ALIGN_UP(), ALIGN_UP_POW2() and MAX(), which, beyond being duplicates, the ALIGN_UP_POW2() is also buggy - Fix objtool klp-diff regression caused by a recent change to the bug table format - Fix klp-build vs CONFIG_MODULE_SRCVERSION_ALL build failure * tag 'objtool-urgent-2026-02-01' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: livepatch/klp-build: Fix klp-build vs CONFIG_MODULE_SRCVERSION_ALL objtool/klp: Fix bug table handling for __WARN_printf() objtool: Replace custom macros in elf.c with shared ones objtool: Print bfd_vma as unsigned long long on ia32-x86_64 cross build
14 daysMerge tag 'kbuild-fixes-6.19-3' of ↵Linus Torvalds3-36/+34
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
14 dayskbuild: Do not run kernel-doc when building external modulesNathan Chancellor1-0/+2
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 Torvalds3-14/+35
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-29livepatch/klp-build: Require Clang assembler >= 20Josh Poimboeuf1-0/+4
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-28kbuild: Fix permissions of modules.builtin.modinfoEthan Zuo1-1/+2
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 Chancellor1-35/+30
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-27livepatch/klp-build: Fix klp-build vs CONFIG_MODULE_SRCVERSION_ALLJosh Poimboeuf1-4/+4
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 Ha1-1/+1
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 Torvalds1-0/+2
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 He1-0/+2
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-18scripts: generate_rust_analyzer: compile sysroot with correct editionTamir Duberstein1-3/+26
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 Duberstein1-0/+1
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 Yang1-1/+1
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 Yang1-1/+1
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 Özkan1-3/+0
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 Ojeda1-1/+1
`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-14scripts: generate_rust_analyzer: Add pin_init_internal depsTamir Duberstein1-1/+1
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 Duberstein1-1/+1
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 Duberstein1-1/+1
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 Kozdra1-5/+6
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 Llamas1-1/+1
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-11Merge tag 'libcrypto-for-linus' of ↵Linus Torvalds1-1/+1
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
2026-01-11treewide: Update email addressThomas Gleixner1-1/+1
In a vain attempt to consolidate the email zoo switch everything to the kernel.org account. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-01-08lib/crypto: tests: Fix syntax error for old python versionsJie Zhan1-1/+1
'make binrpm-pkg' throws me this error, with Python 3.9: *** Error compiling '.../gen-hash-testvecs.py'... File ".../scripts/crypto/gen-hash-testvecs.py", line 121 return f'{alg.upper().replace('-', '_')}_DIGEST_SIZE' ^ SyntaxError: f-string: unmatched '(' Old python versions, presumably <= 3.11, can't resolve these quotes. Fix it with double quotes for compatibility. Fixes: 15c64c47e484 ("lib/crypto: tests: Add SHA3 kunit tests") Signed-off-by: Jie Zhan <zhanjie9@hisilicon.com> Link: https://lore.kernel.org/r/20260107015829.2000699-1-zhanjie9@hisilicon.com Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-01-04rust: fix off-by-one line number in rustdoc testsGary Guo1-1/+1
When the `#![allow]` line was added, the doctest line number anchor isn't updated which causes the line number printed in kunit test to be off-by-one. Fixes: ab844cf32058 ("rust: allow `unreachable_pub` for doctests") Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: David Gow <davidgow@google.com> Link: https://patch.msgid.link/20251211182208.2791025-1-gary@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-12-27mcb: Add missing modpost build supportJose Javier Rodriguez Barbarin2-0/+12
mcb bus is not prepared to autoload client drivers with the data defined on the drivers' MODULE_DEVICE_TABLE. modpost cannot access to mcb_table_id inside MODULE_DEVICE_TABLE so the data declared inside is ignored. Add modpost build support for accessing to the mcb_table_id coded on device drivers' MODULE_DEVICE_TABLE. Fixes: 3764e82e5150 ("drivers: Introduce MEN Chameleon Bus") Reviewed-by: Jorge Sanjuan Garcia <dev-jorge.sanjuangarcia@duagon.com> Signed-off-by: Jose Javier Rodriguez Barbarin <dev-josejavier.rodriguez@duagon.com> Acked-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Link: https://patch.msgid.link/20251202084200.10410-1-dev-josejavier.rodriguez@duagon.com Signed-off-by: Nicolas Schier <nsc@kernel.org>
2025-12-27kbuild: fix compilation of dtb specified on command-line without make ruleThomas De Schampheleire1-12/+14
Since commit e7e2941300d2 ("kbuild: split device tree build rules into scripts/Makefile.dtbs"), it is no longer possible to compile a device tree blob that is not specified in a make rule like: dtb-$(CONFIG_FOO) += foo.dtb Before the mentioned commit, one could copy a dts file to e.g. arch/arm64/boot/dts/ (or a new subdirectory) and then convert it to a dtb file using: make ARCH=arm64 foo.dtb In this scenario, both 'dtb-y' and 'dtb-' are empty, and the inclusion of scripts/Makefile.dtbs relies on 'targets' to contain the MAKECMDGOALS. The value of 'targets', however, is only final later in the code. Move the conditional include of scripts/Makefile.dtbs down to where the value of 'targets' is final. Since Makefile.dtbs updates 'always-y' which is used as a prerequisite in the build rule, the build rule also needs to move down. Fixes: e7e2941300d2 ("kbuild: split device tree build rules into scripts/Makefile.dtbs") Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20251126100017.1162330-1-thomas.de_schampheleire@nokia.com Signed-off-by: Nicolas Schier <nsc@kernel.org>
2025-12-27Revert "scripts/clang-tools: Handle included .c files in gen_compile_commands"Nicolas Schier1-128/+7
This reverts commit 9362d34acf91a706c543d919ade3e651b9bd2d6f. Dmitry Vyukov reported that commit 9362d34acf91 ("scripts/clang-tools: Handle included .c files in gen_compile_commands") generates false entries in some cases for C files that are included in other C files but not meant for standalone compilation. For properly supporting clangd, including .c files is discouraged. Reported-by: Dmitry Vyukov <dvyukov@google.com> Closes: https://lore.kernel.org/r/CACT4Y+Z8aCz0XcoJx9XXPHZSZHxGF8Kx9iUbFarhpTSEPDhMfg@mail.gmail.com Acked-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Dmitry Vyukov <dvyukov@google.com> Fixes: 9362d34acf91 ("scripts/clang-tools: Handle included .c files in gen_compile_commands") Link: https://patch.msgid.link/20251217-revert-scripts-clang-rools-handle-included-c-files-v1-1-def5651446da@kernel.org Signed-off-by: Nicolas Schier <nsc@kernel.org>
2025-12-21Coccinelle: pm_runtime: Fix typo in report messageThorsten Blum1-1/+1
s/Unecessary/Unnecessary/ Reviewed-by: Julia Lawall <julia.lawall@inria.fr> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
2025-12-21scripts: coccicheck: filter *.cocci files by MODESongwei Chai1-1/+5
Enhance the coccicheck script to filter *.cocci files based on the specified MODE (e.g., report, patch). This ensures that only compatible semantic patch files are executed, preventing errors such as: "virtual rule report not supported" This error occurs when a .cocci file does not define a 'virtual <MODE>' rule, yet is executed in that mode. For example: make coccicheck M=drivers/hwtracing/coresight/ MODE=report In this case, running "secs_to_jiffies.cocci" would trigger the error because it lacks support for 'report' mode. With this change, such files are skipped automatically, improving robustness and developer experience. Signed-off-by: Songwei Chai <quic_songchai@quicinc.com> Reviewed-by: Julia Lawall <Julia.Lawall@inria.fr>
2025-12-13Merge tag 'mm-nonmm-stable-2025-12-11-11-47' of ↵Linus Torvalds1-0/+6
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc updates from Andrew Morton: "There are no significant series in this small merge. Please see the individual changelogs for details" [ Editor's note: it's mainly ocfs2 and a couple of random fixes ] * tag 'mm-nonmm-stable-2025-12-11-11-47' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm: memfd_luo: add CONFIG_SHMEM dependency mm: shmem: avoid build warning for CONFIG_SHMEM=n ocfs2: fix memory leak in ocfs2_merge_rec_left() ocfs2: invalidate inode if i_mode is zero after block read ocfs2: avoid -Wflex-array-member-not-at-end warning ocfs2: convert remaining read-only checks to ocfs2_emergency_state ocfs2: add ocfs2_emergency_state helper and apply to setattr checkpatch: add uninitialized pointer with __free attribute check args: fix documentation to reflect the correct numbers ocfs2: fix kernel BUG in ocfs2_find_victim_chain liveupdate: luo_core: fix redundant bound check in luo_ioctl() ocfs2: validate inline xattr size and entry count in ocfs2_xattr_ibody_list fs/fat: remove unnecessary wrapper fat_max_cache() ocfs2: replace deprecated strcpy with strscpy ocfs2: check tl_used after reading it from trancate log inode liveupdate: luo_file: don't use invalid list iterator
2025-12-10checkpatch: add uninitialized pointer with __free attribute checkAlly Heev1-0/+6
Uinitialized pointers with __free attribute can cause undefined behavior as the memory randomly assigned to the pointer is freed automatically when the pointer goes out of scope. add check in checkpatch to detect such issues. Link: https://lkml.kernel.org/r/20251203-aheev-checkpatch-uninitialized-free-v7-1-841e3b31d8f3@gmail.com Signed-off-by: Ally Heev <allyheev@gmail.com> Suggested-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/all/8a4c0b43-cf63-400d-b33d-d9c447b7e0b9@suswa.mountain/ Link: https://lore.kernel.org/all/58fd478f408a34b578ee8d949c5c4b4da4d4f41d.camel@HansenPartnership.com/ Acked-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Joe Perches <joe@perches.com> Cc: Andy Whitcroft <apw@canonical.com> Cc: David Hunter <david.hunter.linux@gmail.com> Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: James Bottomley <james.bottomley@HansenPartnership.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com> Cc: Menon, Nishanth <nm@ti.com> Cc: Stephen Boyd <sboyd@kernel.org> Cc: Viresh Kumar <vireshk@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-12-10Merge tag 'kbuild-6.19-2' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux Pull Kbuild fix from Nathan Chancellor: - Fix install-extmod-build when ccache is used via CC * tag 'kbuild-6.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux: kbuild: install-extmod-build: Properly fix CC expansion when ccache is used
2025-12-10Merge tag 'trace-v6.19-4' of ↵Linus Torvalds1-0/+3
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracing fixes from Steven Rostedt: - Fix unused tracepoint build for modules only using exported tracepoints The tracepoint-update.c code that looks for unused tracepoints expects if tracepoints are used then it will have tracepoints defined. If not, it errors out which fails the build. In most cases this the way things work. A tracepoint can't be used if it is not defined. There is one exception; If a module only uses tracepoints that are defined in other modules or the vmlinux proper, where the tracepoints are exported. In this case, the tracepoint-update.c code thinks tracepoints are used but not defined and errors out, failing the build. When tracepoint-update.c detects this case, if it is a module that is being processed, exit out normally as it is a legitimate case. - Add tracepoint-update.c to MAINTAINERS file The tracepoint-update.c file is specific to tracing so add it to the tracing subsystem in the MAINTAINERS file. * tag 'trace-v6.19-4' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: MAINTAINERS: Add tracepoint-update.c to TRACING section tracing: Fix unused tracepoints when module uses only exported ones
2025-12-09tracing: Fix unused tracepoints when module uses only exported onesSteven Rostedt1-0/+3
Building the KVM intel module failed to build with UT=1: no __tracepoint_strings in file: arch/x86/kvm/kvm-intel.o make[3]: *** [/work/git/test-linux.git/scripts/Makefile.modfinal:62: arch/x86/kvm/kvm-intel.ko] Error 1 The reason is that the module only uses the tracepoints defined and exported by the main kvm module. The tracepoint-update.c code fails the build if a tracepoint is used, but there's no tracepoints defined. But this is acceptable in modules if the tracepoints are defined in the vmlinux proper or another module and exported. Do not fail to build if a tracepoint is used but no tracepoints are defined if the code is a module. This should still never happen for the vmlinux itself. Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Masahiro Yamada <masahiroy@kernel.org> Link: https://patch.msgid.link/20251209204023.76941824@fedora Fixes: e30f8e61e2518 ("tracing: Add a tracepoint verification check at build time") Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-12-10Merge tag 'pm-6.19-rc1-2' of ↵Linus Torvalds1-1/+0
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull more power management updates from Rafael Wysocki: "Fix a runtime PM unit test added during the 6.18 development cycle and change the pm_runtime_barrier() return type to void (Brian Norris)" * tag 'pm-6.19-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: coccinelle: Drop pm_runtime_barrier() error code checks PM: runtime: Make pm_runtime_barrier() return void PM: runtime: Stop checking pm_runtime_barrier() return code
2025-12-06Merge tag 'mm-nonmm-stable-2025-12-06-11-14' of ↵Linus Torvalds5-19/+492
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull non-MM updates from Andrew Morton: - "panic: sys_info: Refactor and fix a potential issue" (Andy Shevchenko) fixes a build issue and does some cleanup in ib/sys_info.c - "Implement mul_u64_u64_div_u64_roundup()" (David Laight) enhances the 64-bit math code on behalf of a PWM driver and beefs up the test module for these library functions - "scripts/gdb/symbols: make BPF debug info available to GDB" (Ilya Leoshkevich) makes BPF symbol names, sizes, and line numbers available to the GDB debugger - "Enable hung_task and lockup cases to dump system info on demand" (Feng Tang) adds a sysctl which can be used to cause additional info dumping when the hung-task and lockup detectors fire - "lib/base64: add generic encoder/decoder, migrate users" (Kuan-Wei Chiu) adds a general base64 encoder/decoder to lib/ and migrates several users away from their private implementations - "rbree: inline rb_first() and rb_last()" (Eric Dumazet) makes TCP a little faster - "liveupdate: Rework KHO for in-kernel users" (Pasha Tatashin) reworks the KEXEC Handover interfaces in preparation for Live Update Orchestrator (LUO), and possibly for other future clients - "kho: simplify state machine and enable dynamic updates" (Pasha Tatashin) increases the flexibility of KEXEC Handover. Also preparation for LUO - "Live Update Orchestrator" (Pasha Tatashin) is a major new feature targeted at cloud environments. Quoting the cover letter: This series introduces the Live Update Orchestrator, a kernel subsystem designed to facilitate live kernel updates using a kexec-based reboot. This capability is critical for cloud environments, allowing hypervisors to be updated with minimal downtime for running virtual machines. LUO achieves this by preserving the state of selected resources, such as memory, devices and their dependencies, across the kernel transition. As a key feature, this series includes support for preserving memfd file descriptors, which allows critical in-memory data, such as guest RAM or any other large memory region, to be maintained in RAM across the kexec reboot. Mike Rappaport merits a mention here, for his extensive review and testing work. - "kexec: reorganize kexec and kdump sysfs" (Sourabh Jain) moves the kexec and kdump sysfs entries from /sys/kernel/ to /sys/kernel/kexec/ and adds back-compatibility symlinks which can hopefully be removed one day - "kho: fixes for vmalloc restoration" (Mike Rapoport) fixes a BUG which was being hit during KHO restoration of vmalloc() regions * tag 'mm-nonmm-stable-2025-12-06-11-14' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (139 commits) calibrate: update header inclusion Reinstate "resource: avoid unnecessary lookups in find_next_iomem_res()" vmcoreinfo: track and log recoverable hardware errors kho: fix restoring of contiguous ranges of order-0 pages kho: kho_restore_vmalloc: fix initialization of pages array MAINTAINERS: TPM DEVICE DRIVER: update the W-tag init: replace simple_strtoul with kstrtoul to improve lpj_setup KHO: fix boot failure due to kmemleak access to non-PRESENT pages Documentation/ABI: new kexec and kdump sysfs interface Documentation/ABI: mark old kexec sysfs deprecated kexec: move sysfs entries to /sys/kernel/kexec test_kho: always print restore status kho: free chunks using free_page() instead of kfree() selftests/liveupdate: add kexec test for multiple and empty sessions selftests/liveupdate: add simple kexec-based