kernel/Makefile, branch master

Linux 7.0-rc4

2026-03-15T20:52:05Z

Merge tag 'rust-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux

2026-03-14T19:35:16Z

Pull Rust fixes from Miguel Ojeda: "Toolchain and infrastructure: - Remap paths to avoid absolute ones starting with the upcoming Rust 1.95.0 release. This improves build reproducibility, avoids leaking the exact path and avoids having the same path appear in two forms The approach here avoids remapping debug information as well, in order to avoid breaking tools that used the paths to access source files, which was the previous attempt that needed to be reverted - Allow 'unused_features' lint for the upcoming Rust 1.96.0 release. While well-intentioned, we do not benefit much from the new lint - Emit dependency information into '$(depfile)' directly to avoid a temporary '.d' file (it was an old approach) 'kernel' crate: - 'str' module: fix warning under '!CONFIG_BLOCK' by making 'NullTerminatedFormatter' public - 'cpufreq' module: suppress false positive Clippy warning 'pin-init' crate: - Remove '#[disable_initialized_field_access]' attribute which was unsound. This means removing the support for structs with unaligned fields (through the 'repr(packed)' attribute), for now And document the load-bearing fact of field accessors (i.e. that they are required for soundness) - Replace shadowed return token by 'unsafe'-to-create token in order to remain sound in the face of the likely upcoming Type Alias Impl Trait (TAIT) and the next trait solver in upstream Rust" * tag 'rust-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: rust: kbuild: allow `unused_features` rust: cpufreq: suppress clippy::double_parens in Policy doctest rust: pin-init: replace shadowed return token by `unsafe`-to-create token rust: pin-init: internal: init: document load-bearing fact of field accessors rust: pin-init: internal: init: remove `#[disable_initialized_field_access]` rust: build: remap path to avoid absolute path rust: kbuild: emit dep-info into $(depfile) directly rust: str: make NullTerminatedFormatter public

rust: kbuild: allow `unused_features`

2026-03-12T14:15:16Z

Starting with the upcoming Rust 1.96.0 (to be released 2026-05-28), `rustc` introduces the new lint `unused_features` [1], which warns [2]: warning: feature `used_with_arg` is declared but not used --> :1:93 | 1 | #![feature(asm_const,asm_goto,arbitrary_self_types,lint_reasons,offset_of_nested,raw_ref_op,used_with_arg)] | ^^^^^^^^^^^^^ | = note: `#[warn(unused_features)]` (part of `#[warn(unused)]`) on by default The original goal of using `-Zcrate-attr` automatically was that there is a consistent set of features enabled and managed globally for all Rust kernel code (modulo exceptions like the `rust/` crated). While we could require crates to enable features manually (even if we still keep the `-Zallow-features=` list, i.e. removing the `-Zcrate-attr` list), it is not really worth making all developers worry about it just for a new lint. The features are expected to eventually become stable anyway (most already did), and thus having to remove features in every file that may use them is not worth it either. Thus just allow the new lint globally. The lint actually existed for a long time, which is why `rustc` does not complain about an unknown lint in the stable versions we support, but it was "disabled" years ago [3], and now it was made to work again. For extra context, the new implementation of the lint has already been improved to avoid linting about features that became stable thanks to Benno's report and the ensuing discussion [4] [5], but while that helps, it is still the case that we may have features enabled that are not used for one reason or another in a particular crate. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/152164 [1] Link: https://github.com/Rust-for-Linux/pin-init/pull/114 [2] Link: https://github.com/rust-lang/rust/issues/44232 [3] Link: https://github.com/rust-lang/rust/issues/153523 [4] Link: https://github.com/rust-lang/rust/pull/153610 [5] Reviewed-by: Benno Lossin Reviewed-by: Gary Guo Link: https://patch.msgid.link/20260312111014.74198-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda

Linux 7.0-rc3

2026-03-08T23:56:54Z

Merge tag 'kbuild-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux

2026-03-07T04:27:13Z

Pull Kbuild fixes from Nathan Chancellor: - Split out .modinfo section from ELF_DETAILS macro, as that macro may be used in other areas that expect to discard .modinfo, breaking certain image layouts - Adjust genksyms parser to handle optional attributes in certain declarations, necessary after commit 07919126ecfc ("netfilter: annotate NAT helper hook pointers with __rcu") - Include resolve_btfids in external module build created by scripts/package/install-extmod-build when it may be run on external modules - Avoid removing objtool binary with 'make clean', as it is required for external module builds * tag 'kbuild-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux: kbuild: Leave objtool binary around with 'make clean' kbuild: install-extmod-build: Package resolve_btfids if necessary genksyms: Fix parsing a declarator with a preceding attribute kbuild: Split .modinfo out from ELF_DETAILS

rust: build: remap path to avoid absolute path

2026-03-06T01:00:00Z

When building with an out directory (O=), absolute paths can end up in the file name in `#[track_caller]` or the panic message. This is not desirable as this leaks the exact path being used to build the kernel and means that the same location can appear in two forms (relative or absolute). This is reported by Asahi [1] and is being workaround in [2] previously to force everything to be absolute path. Using absolute path for everything solves the inconsistency, however it does not address the reproducibility issue. So, fix this by remap all absolute paths to srctree to relative path instead. This is previously attempted in commit dbdffaf50ff9 ("kbuild, rust: use -fremap-path-prefix to make paths relative") but that was reverted as remapping debug info causes some tool (e.g. objdump) to be unable to find sources. Therefore, use `--remap-path-scope` to only remap macros but leave debuginfo untouched. `--remap-path-scope` is only stable in Rust 1.95, so use `rustc-option` to detect its presence. This feature has been available as `-Zremap-path-scope` for all versions that we support; however due to bugs in the Rust compiler, it does not work reliably until 1.94. I opted to not enable it for 1.94 as it's just a single version that we missed. This change can be validated by building a kernel with O=, strip debug info on vmlinux, and then check if the absolute path exists in `strings vmlinux`, e.g. `strings vmlinux |grep \/home`. Reported-by: Janne Grunau Reported-by: Asahi Lina Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Per-call-site.20data.20and.20lock.20class.20keys/near/572466559 [1] Link: https://github.com/AsahiLinux/linux/commit/54ab88878869036c9d6620101bfe17a81e88c2f9 [2] Signed-off-by: Gary Guo Acked-by: Nicolas Schier # kbuild Link: https://patch.msgid.link/20260226152112.3222886-1-gary@kernel.org [ Reworded for few typos. - Miguel ] Signed-off-by: Miguel Ojeda

kbuild: Leave objtool binary around with 'make clean'

2026-03-02T21:22:39Z

The difference between 'make clean' and 'make mrproper' is documented in 'make help' as: clean - Remove most generated files but keep the config and enough build support to build external modules mrproper - Remove all generated files + config + various backup files After commit 68b4fe32d737 ("kbuild: Add objtool to top-level clean target"), running 'make clean' then attempting to build an external module with the resulting build directory fails with $ make ARCH=x86_64 O=build clean $ make -C build M=... MO=... ... /bin/sh: line 1: .../build/tools/objtool/objtool: No such file or directory as 'make clean' removes the objtool binary. Split the objtool clean target into mrproper and clean like Kbuild does and remove all generated artifacts with 'make clean' except for the objtool binary, which is removed with 'make mrproper'. To avoid a small race when running the objtool clean target through both objtool_mrproper and objtool_clean when running 'make mrproper', modify objtool's clean up find command to avoid using find's '-delete' command by piping the files into 'xargs rm -f' like the rest of Kbuild does. Cc: stable@vger.kernel.org Fixes: 68b4fe32d737 ("kbuild: Add objtool to top-level clean target") Reported-by: Michal Suchanek Closes: https://lore.kernel.org/20260225112633.6123-1-msuchanek@suse.de/ Reported-by: Rainer Fiebig Closes: https://lore.kernel.org/62d12399-76e5-3d40-126a-7490b4795b17@mailbox.org/ Acked-by: Josh Poimboeuf Acked-by: Peter Zijlstra (Intel) Reviewed-by: Nicolas Schier Tested-by: Nicolas Schier Link: https://patch.msgid.link/20260227-avoid-objtool-binary-removal-clean-v1-1-122f3e55eae9@kernel.org Signed-off-by: Nathan Chancellor

Linux 7.0-rc2

2026-03-01T23:39:31Z

Linux 7.0-rc1

2026-02-22T21:18:59Z

Merge tag 'kbuild-fixes-7.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux

2026-02-18T22:59:55Z

Pull Kbuild fixes from Nathan Chancellor: - Ensure tools/objtool is cleaned by 'make clean' and 'make mrproper' - Fix test program for CONFIG_CC_CAN_LINK to avoid a warning, which is made fatal by -Werror - Drop explicit LZMA parallel compression in scripts/make_fit.py - Several fixes for commit 62089b804895 ("kbuild: rpm-pkg: Generate debuginfo package manually") * tag 'kbuild-fixes-7.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux: kbuild: rpm-pkg: Disable automatic requires for manual debuginfo package kbuild: rpm-pkg: Fix manual debuginfo generation when using .src.rpm kernel: rpm-pkg: Restore find-debuginfo.sh approach to -debuginfo package kbuild: rpm-pkg: Restrict manual debug package creation scripts/make_fit.py: Drop explicit LZMA parallel compression kbuild: Fix CC_CAN_LINK detection kbuild: Add objtool to top-level clean target