summaryrefslogtreecommitdiff
path: root/Makefile
AgeCommit message (Collapse)AuthorFilesLines
5 daysLinux 6.18.48v6.18.48linux-6.18.yGreg Kroah-Hartman1-1/+1
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6 daysLinux 6.18.47v6.18.47Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260825132541.887883084@linuxfoundation.org Tested-by: Pavel Machek (CIP) <pavel@nabladev.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 daysLinux 6.18.46v6.18.46Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260820145237.531699751@linuxfoundation.org Tested-by: Pavel Machek (CIP) <pavel@nabladev.com> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Barry K. Nathan <barryn@pobox.com> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
14 daysLinux 6.18.45v6.18.45Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260817132536.466235697@linuxfoundation.org Tested-by: Pavel Machek (CIP) <pavel@nabladev.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Barry K. Nathan <barryn@pobox.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-09Linux 6.18.44v6.18.44Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260807143424.272339768@linuxfoundation.org Tested-by: Pavel Machek (CIP) <pavel@nabladev.com> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-06Linux 6.18.43v6.18.43Greg Kroah-Hartman1-1/+1
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-03Linux 6.18.42v6.18.42Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260730141445.110192266@linuxfoundation.org Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Pavel Machek (CIP) <pavel@nabladev.com> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Ron Economos <re@w6rz.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-08-03rust: allow `clippy::unwrap_or_default` globallyAlexandre Courbot1-0/+5
commit 4688cf884b3abcd12498e03b625d1916bf49a1e4 upstream. Starting with rustc 1.88, the `clippy::unwrap_or_default` lint triggers on `rust/kernel/soc.rs` if `CONFIG_CC_OPTIMIZE_FOR_SIZE=y`: warning: use of `unwrap_or` to construct default value --> ../rust/kernel/soc.rs:66:10 | 66 | .unwrap_or(core::ptr::null()) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `unwrap_or_default()` This is a clippy bug [1]: the lint decides whether an expression is equivalent to `Default::default()` by inspecting the optimized MIR of `<*const T as Default>::default` exported by `core`, so its outcome depends on the optimization level `core` was built with. Moreover, its suggestion ignores our MSRV of 1.85 (`Default` for `*const T` is only stable since Rust 1.88), so we could not apply it anyway. Disable the lint globally rather than working around this single occurrence; it can be re-enabled conditionally using `rustc-min-version` once clippy is fixed. Link: https://github.com/rust-lang/rust-clippy/issues/17379 [1] Suggested-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://patch.msgid.link/20260708-soc_unwrap_or-v2-1-007ed724cc7b@nvidia.com [ Moved to non-versioned group. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-30Linux 6.18.41v6.18.41Greg Kroah-Hartman1-1/+1
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-24Linux 6.18.40v6.18.40Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260721152514.750365251@linuxfoundation.org Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Pavel Machek (CIP) <pavel@nabladev.com> Link: https://lore.kernel.org/r/20260722142910.893804136@linuxfoundation.org Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Pavel Machek (CIP) <pavel@nabladev.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-18Linux 6.18.39v6.18.39Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260716133044.672218725@linuxfoundation.org Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Pavel Machek (CIP) <pavel@nabladev.com> Link: https://lore.kernel.org/r/20260717101904.922623678@linuxfoundation.org Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Pavel Machek (CIP) <pavel@nabladev.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-18rust: Kbuild: set frame-pointer llvm module flag for CONFIG_FRAME_POINTERAlice Ryhl1-0/+3
commit 191f49f1e38b1c10eb44b0f967c6175c884ef7db upstream. Due to a rustc bug, the -Cforce-frame-pointers=y flag only emits the frame-pointer annotation for functions, but not for the module. This means that functions generated by the LLVM backend such as 'asan.module_ctor' do not receive the frame-pointer annotation. This is likely to lead to broken backtraces and may also cause issues with ftrace if these features are used with functions generated by the LLVM backend. Thus, use -Zllvm_module_flag to work around this rustc bug if using a rustc without the fix. [ The fix [1] has landed for Rust 1.98.0 (expected release on 2026-08-20). - Miguel ] Cc: stable@vger.kernel.org # 6.12.y and later (flag not available in pinned Rust in older LTSs). Fixes: 2f7ab1267dc9 ("Kbuild: add Rust support") Link: https://github.com/rust-lang/rust/pull/156980 [1] Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260616-frame-ptr-fix-v1-1-dc6b29a631d9@google.com [ - Adjusted Cc: stable@ as discussed. - Added comment with link to the PR, similar to what we did in commit ac35b5580ace ("rust: arm64: set uwtable llvm module flag for CONFIG_UNWIND_TABLES"). - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-04Linux 6.18.38v6.18.38Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260702155112.110058792@linuxfoundation.org Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> Link: https://lore.kernel.org/r/20260703072816.644513463@linuxfoundation.org Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-04gcov: use atomic counter updates to fix concurrent access crashesKonstantin Khorenko1-6/+21
commit 56cb9b7d96b28a1173a510ab25354b6599ad3a33 upstream. GCC's GCOV instrumentation can merge global branch counters with loop induction variables as an optimization. In inflate_fast(), the inner copy loops get transformed so that the GCOV counter value is loaded multiple times to compute the loop base address, start index, and end bound. Since GCOV counters are global (not per-CPU), concurrent execution on different CPUs causes the counter to change between loads, producing inconsistent values and out-of-bounds memory writes. The crash manifests during IPComp (IP Payload Compression) processing when inflate_fast() runs concurrently on multiple CPUs: BUG: unable to handle page fault for address: ffffd0a3c0902ffa RIP: inflate_fast+1431 Call Trace: zlib_inflate __deflate_decompress crypto_comp_decompress ipcomp_decompress [xfrm_ipcomp] ipcomp_input [xfrm_ipcomp] xfrm_input At the crash point, the compiler generated three loads from the same global GCOV counter (__gcov0.inflate_fast+216) to compute base, start, and end for an indexed loop. Another CPU modified the counter between loads, making the values inconsistent - the write went 3.4 MB past a 65 KB buffer. Add -fprofile-update=prefer-atomic to CFLAGS_GCOV at the global level in the top-level Makefile, guarded by a try-run compile test. The test compiles a minimal program with and without -fprofile-update=prefer-atomic using the full KBUILD_CFLAGS, then compares undefined symbols in the resulting object files. If prefer-atomic introduces new undefined references (such as __atomic_fetch_add_8 on i386 or __aarch64_ldadd8_relax on arm64 with outline-atomics), the flag is not added -- the kernel does not link against libatomic. On architectures where GCC inlines 64-bit atomic counter updates (x86_64, s390, ...) the test passes and the flag is enabled, preventing the compiler from merging counters with loop induction variables and fixing the observed concurrent-access crash. On architectures where the flag would introduce libatomic dependencies, it is silently omitted and behaviour is no worse than before this patch. Move the CFLAGS_GCOV block from its original position (before the arch Makefile include) to after the core KBUILD_CFLAGS assignments but before the scripts/Makefile.gcc-plugins include. This placement ensures the try-run test sees arch-specific flags (-m32, -march=, -mno-outline-atomics) while avoiding GCC plugin flags (-fplugin=) that would break the test on clean builds when plugin shared objects do not yet exist. Link: https://lore.kernel.org/20260511105052.417187-2-khorenko@virtuozzo.com Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com> Tested-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Peter Oberparleiter <oberpar@linux.ibm.com> Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Miguel Ojeda <ojeda@kernel.org> Cc: Mikhail Zaslonko <zaslonko@linux.ibm.com> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Cc: Thomas Weißschuh <linux@weissschuh.net> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-06-27Linux 6.18.37v6.18.37Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260625125645.554579168@linuxfoundation.org Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-06-19Linux 6.18.36v6.18.36Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260616145057.827196531@linuxfoundation.org Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Pavel Machek (CIP) <pavel@nabladev.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-06-19rust: kasan/kbuild: fix rustc-option when cross-compilingAlice Ryhl1-1/+2
commit 4a44b17406cb5a93f90af3df9392b3a45eb336fb upstream. The Makefile version of rustc-option currently checks whether the option exists for the host target instead of the target actually being compiled for. It was done this way in commit 46e24a545cdb ("rust: kasan/kbuild: fix missing flags on first build") to avoid a circular dependency on target.json. However, because of this, rustc-option currently does not function when cross-compiling from x86_64 to aarch64 if CONFIG_SHADOW_CALL_STACK is enabled. This is because KBUILD_RUSTFLAGS contains -Zfixed-x18 under this configuration. Since that flag does not exist on the host target, rustc-option runs into a compilation failure every time, leading to all flags being rejected as unsupported. To fix this, update rustc-option to pass a --target parameter so that the host target is not used. For targets using target.json, use a built-in target that is as close as possible to the target created with target.json to avoid the circular dependency on target.json. One scenario where this causes a boot failure: * Cross-compiled from x86_64 to aarch64. * With CONFIG_SHADOW_CALL_STACK=y * With CONFIG_KASAN_SW_TAGS=y * With CONFIG_KASAN_INLINE=n Then the resulting kernel image will fail to boot when it first calls into Rust code with a crash along the lines of "Unable to handle kernel paging request at virtual address 0ffffffc08541796". This is because the call threshold is not specified, so rustc will inline kasan operations, but the kasan shadow offset is not specified, which leads to the inlined kasan instructions being incorrect. Note that the -Zsanitizer=kernel-hwaddress parameter itself does not lead to a rustc-option failure despite being aarch64-specific because RUSTFLAGS_KASAN has not yet been added to KBUILD_RUSTFLAGS when rustc-option is evaluated by the kasan Makefile. Cc: stable@vger.kernel.org Fixes: 46e24a545cdb ("rust: kasan/kbuild: fix missing flags on first build") Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260507-rustc-option-cross-v2-1-2f650a49c2b5@google.com [ Edited slightly: - Reset variable to avoid using the environment. - Use a simply expanded variable flavor for simplicity. - Export variable so that behavior in sub-`make`s is consistent. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> This matches other variables. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-06-09Linux 6.18.35v6.18.35Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260607095727.528828913@linuxfoundation.org Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-06-01Linux 6.18.34v6.18.34Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260528194638.371537336@linuxfoundation.org Tested-by: Ron Economos <re@w6rz.net> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Pavel Machek (CIP) <pavel@nabladev.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-23Linux 6.18.33v6.18.33Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260520162134.554764788@linuxfoundation.org Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Pavel Machek (CIP) <pavel@nabladev.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Ron Economos <re@w6rz.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-23kbuild: Never respect CONFIG_WERROR / W=e to fixdepThomas Weißschuh1-0/+2
[ Upstream commit 75f7c47ccd78c947cf1b6ddb18ea453ff0555716 ] The fixdep hostprog may be built multiple times during a single build. Once during the configuration phase and later during the regular phase. As only the regular build phase respects CONFIG_WERROR / W=e, the compiler flags might change between the phases, leading to rebuilds. Example, the rebuilds will happen twice on each invocation of the build: $ make allyesconfig prepare make[1]: Entering directory '/tmp/deleteme' HOSTCC scripts/basic/fixdep # # No change to .config # HOSTCC scripts/basic/fixdep DESCEND objtool INSTALL libsubcmd_headers make[1]: Leaving directory '/tmp/deleteme' Fix the compilation flags used for scripts/basic/ before scripts/Makefile.warn is evaluated to stop CONFIG_WERROR / W=e influencing the fixdep build to avoid the spurious rebuilds. Fixes: 7ded7d37e5f5 ("scripts/Makefile.extrawarn: Respect CONFIG_WERROR / W=e for hostprogs") Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20260422-kbuild-scripts-basic-werror-v1-1-8c6912ff22e0@weissschuh.net Signed-off-by: Nicolas Schier <nsc@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-05-17Linux 6.18.32v6.18.32Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260515154657.309489048@linuxfoundation.org Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Pavel Machek (CIP) <pavel@nabladev.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Brett A C Sheffield <bacs@librecast.net> Link: https://lore.kernel.org/r/20260516102236.209957148@linuxfoundation.org Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Wentao Guan <guanwentao@uniontech.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-15Linux 6.18.31v6.18.31Greg Kroah-Hartman1-1/+1
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-14Linux 6.18.30v6.18.30Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260512173938.452574370@linuxfoundation.org Tested-by: Pavel Machek (CIP) <pavel@nabladev.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20260513153744.746440810@linuxfoundation.org Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Barry K. Nathan <barryn@pobox.com> Tested-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-14rust: allow `clippy::collapsible_if` globallyMiguel Ojeda1-0/+1
commit 2adc8664018c1cc595c7c0c98474a33c7fe32a85 upstream. Similar to `clippy::collapsible_match` (globally allowed in the previous commit), the `clippy::collapsible_if` lint [1] can make code harder to read in certain cases. Thus just let developers decide on their own. In addition, remove the existing `expect` we had. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Suggested-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/rust-for-linux/DGROP5CHU1QZ.1OKJRAUZXE9WC@garyguo.net/ Link: https://rust-lang.github.io/rust-clippy/master/index.html#collapsible_if [1] Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260426144201.227108-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-14rust: allow `clippy::collapsible_match` globallyMiguel Ojeda1-0/+1
commit 838d852da8503372f3a1779bfbd1ccb93153ab4e upstream. The `clippy::collapsible_match` lint [1] can make code harder to read in certain cases [2], e.g. CLIPPY P rust/libmacros.so - due to command line change warning: this `if` can be collapsed into the outer `match` --> rust/pin-init/internal/src/helpers.rs:91:17 | 91 | / if nesting == 1 { 92 | | impl_generics.push(tt.clone()); 93 | | impl_generics.push(tt); 94 | | skip_until_comma = false; 95 | | } | |_________________^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#collapsible_match = note: `-W clippy::collapsible-match` implied by `-W clippy::all` = help: to override `-W clippy::all` add `#[allow(clippy::collapsible_match)]` help: collapse nested if block | 90 ~ TokenTree::Punct(p) if skip_until_comma && p.as_char() == ',' 91 ~ && nesting == 1 => { 92 | impl_generics.push(tt.clone()); 93 | impl_generics.push(tt); 94 | skip_until_comma = false; 95 ~ } | The lint does not have much upside -- when the suggestion may be a good one, it would still read fine when nested anyway. And it is the kind of lint that may easily bias people to just apply the suggestion instead of allowing it. [ In addition, as Gary points out [3], the suggestion is also wrong [4] and in the process of being fixed [5], possibly for Rust 1.97.0: Link: https://lore.kernel.org/rust-for-linux/DI3YV94TH9I3.1SOHW51552497@garyguo.net/ [3] Link: https://github.com/rust-lang/rust-clippy/issues/16875 [4] Link: https://github.com/rust-lang/rust-clippy/pull/16878 [5] - Miguel ] Thus just let developers decide on their own. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://rust-lang.github.io/rust-clippy/master/index.html#collapsible_match [1] Link: https://lore.kernel.org/rust-for-linux/CANiq72nWYJna_hdFxjQCQZK6yJBrr1Mb86iKavivV0U0BgufeA@mail.gmail.com/ [2] Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260426144201.227108-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11Linux 6.18.29v6.18.29Greg Kroah-Hartman1-1/+1
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-08Linux 6.18.28v6.18.28Greg Kroah-Hartman1-1/+1
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-07Linux 6.18.27v6.18.27Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260504135142.929052779@linuxfoundation.org Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Dileep Malepu <dileep.debian@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-07kbuild: rust: allow `clippy::uninlined_format_args`Miguel Ojeda1-0/+1
commit 10eea3c147141c90cf409b8df56d245c9d7f88d9 upstream. Clippy in Rust 1.88.0 (only) reports [1]: warning: variables can be used directly in the `format!` string --> rust/macros/module.rs:112:23 | 112 | let content = format!("{param}:{content}", param = param, content = content); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args = note: `-W clippy::uninlined-format-args` implied by `-W clippy::all` = help: to override `-W clippy::all` add `#[allow(clippy::uninlined_format_args)]` help: change this to | 112 - let content = format!("{param}:{content}", param = param, content = content); 112 + let content = format!("{param}:{content}"); warning: variables can be used directly in the `format!` string --> rust/macros/module.rs:198:14 | 198 | t => panic!("Unsupported parameter type {}", t), | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args = note: `-W clippy::uninlined-format-args` implied by `-W clippy::all` = help: to override `-W clippy::all` add `#[allow(clippy::uninlined_format_args)]` help: change this to | 198 - t => panic!("Unsupported parameter type {}", t), 198 + t => panic!("Unsupported parameter type {t}"), | The reason it only triggers in that version is that the lint was moved from `pedantic` to `style` in Rust 1.88.0 and then back to `pedantic` in Rust 1.89.0 [2][3]. In the first case, the suggestion is fair and a pure simplification, thus we will clean it up separately. To keep the behavior the same across all versions, and since the lint does not work for all macros (e.g. custom ones like `pr_info!`), disable it globally. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://lore.kernel.org/rust-for-linux/CANiq72=drAtf3y_DZ-2o4jb6Az9J3Yj4QYwWnbRui4sm4AJD3Q@mail.gmail.com/ [1] Link: https://github.com/rust-lang/rust-clippy/pull/15287 [2] Link: https://github.com/rust-lang/rust-clippy/issues/15151 [3] Link: https://patch.msgid.link/20260331205849.498295-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-30Linux 6.18.26v6.18.26Greg Kroah-Hartman1-1/+1
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-27Linux 6.18.25v6.18.25Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260424132430.006424517@linuxfoundation.org Tested-by: Pavel Machek (CIP) <pavel@nabladev.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Dileep Malepu <dileep.debian@gmail.com> Tested-by: Barry K. Nathan <barryn@pobox.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-22Linux 6.18.24v6.18.24Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260420153935.605963767@linuxfoundation.org Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Pavel Machek (CIP) <pavel@nabladev.com> Tested-by: Barry K. Nathan <barryn@pobox.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-18Linux 6.18.23v6.18.23Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260413155731.019638460@linuxfoundation.org Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Pavel Machek (CIP) <pavel@nabladev.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Barry K. Nathan <barryn@pobox.com> Tested-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Dileep Malepu <dileep.debian@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-11Linux 6.18.22v6.18.22Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260408175933.836769063@linuxfoundation.org Tested-by: Dileep Malepu <dileep.debian@gmail.com> Tested-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> Tested-by: Pavel Machek (CIP) <pavel@nabladev.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20260409092720.599045151@linuxfoundation.org Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-02Linux 6.18.21v6.18.21Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260331161753.468533260@linuxfoundation.org Tested-by: Dileep Malepu <dileep.debian@gmail.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Barry K. Nathan <barryn@pobox.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-02kbuild: Delete .builtin-dtbs.S when running make cleanCharles Mirabile1-1/+1
commit a76e30c2479ce6ffa2aa6c8a8462897afc82bc90 upstream. The makefile tries to delete a file named ".builtin-dtb.S" but the file created by scripts/Makefile.vmlinux is actually called ".builtin-dtbs.S". Fixes: 654102df2ac2a ("kbuild: add generic support for built-in boot DTBs") Cc: stable@vger.kernel.org Signed-off-by: Charles Mirabile <cmirabil@redhat.com> Reviewed-by: Nicolas Schier <nsc@kernel.org> Link: https://patch.msgid.link/20260308044338.181403-1-cmirabil@redhat.com [nathan: Small commit message adjustments] Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-03-25Linux 6.18.20v6.18.20Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260323134503.770111826@linuxfoundation.org Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Jeffrin Jose T <jeffrin@rajagiritech.edu.in> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-03-19Linux 6.18.19v6.18.19Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260317162959.345812316@linuxfoundation.org Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Jeffrin Jose T <jeffrin@rajagiritech.edu.in> Tested-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Ron Economos <re@w6rz.net> Link: https://lore.kernel.org/r/20260318122621.714862892@linuxfoundation.org Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Pavel Machek (CIP) <pavel@nabladev.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Barry K. Nathan <barryn@pobox.com> Tested-by: Mark Brown <brooniekernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-03-19kbuild: Leave objtool binary around with 'make clean'Nathan Chancellor1-4/+4
[ Upstream commit fdb12c8a24a453bdd6759979b6ef1e04ebd4beb4 ] 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 <msuchanek@suse.de> Closes: https://lore.kernel.org/20260225112633.6123-1-msuchanek@suse.de/ Reported-by: Rainer Fiebig <jrf@mailbox.org> Closes: https://lore.kernel.org/62d12399-76e5-3d40-126a-7490b4795b17@mailbox.org/ Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Nicolas Schier <nsc@kernel.org> Tested-by: Nicolas Schier <nsc@kernel.org> Link: https://patch.msgid.link/20260227-avoid-objtool-binary-removal-clean-v1-1-122f3e55eae9@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> [ Context ] Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-03-19rust: kbuild: allow `unused_features`Miguel Ojeda1-0/+1
commit 592c61f3bfceaa29f8275696bd67c3dfad7ef72e upstream. 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 --> <crate attribute>: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 <lossin@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260312111014.74198-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-03-13Linux 6.18.18v6.18.18Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260312200326.246396673@linuxfoundation.org Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Barry K. Nathan <barryn@pobox.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-03-12Linux 6.18.17v6.18.17Sasha Levin1-1/+1
Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Dileep malepu <dileep.debian@gmail.com> Tested-by: Jeffrin Jose T <jeffrin@rajagiritech.edu.in> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Barry K. Nathan <barryn@pobox.com> Tested-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04Linux 6.18.16v6.18.16Sasha Levin1-1/+1
Signed-off-by: Sasha Levin <sashal@kernel.org> Tested-by: Hardik Garg <hargar@linux.microsoft.com> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Barry K. Nathan <barryn@pobox.com> Tested-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Tested-by: Brett Mastbergen <bmastbergen@ciq.com> Tested-by: Brett A C Sheffield <bacs@librecast.net>
2026-02-28Linux 6.18.15v6.18.15Greg Kroah-Hartman1-1/+1
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-27Linux 6.18.14v6.18.14Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260225012348.915798704@linuxfoundation.org Tested-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jeffrin Jose T <jeffrin@rajagiritech.edu.in> Link: https://lore.kernel.org/r/20260225151847.709818960@linuxfoundation.org Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Jeffrin Jose T <jeffrin@rajagiritech.edu.in> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Tested-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-27kbuild: Add objtool to top-level clean targetJosh Poimboeuf1-1/+10
[ Upstream commit 68b4fe32d73789dea23e356f468de67c8367ef8f ] Objtool is an integral part of the build, make sure it gets cleaned by "make clean" and "make mrproper". Fixes: 442f04c34a1a ("objtool: Add tool to perform compile-time stack metadata validation") Reported-by: Jens Remus <jremus@linux.ibm.com> Closes: https://lore.kernel.org/15f2af3b-be33-46fc-b972-6b8e7e0aa52e@linux.ibm.com Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Tested-by: Jens Remus <jremus@linux.ibm.com> Link: https://patch.msgid.link/968faf2ed30fa8b3519f79f01a1ecfe7929553e5.1770759919.git.jpoimboe@kernel.org [nathan: use Closes: instead of Link: per checkpatch.pl] Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-19Linux 6.18.13v6.18.13Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260217200006.470920131@linuxfoundation.org Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Jeffrin Jose T <jeffrin@rajagiritech.edu.in> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-16Linux 6.18.12v6.18.12Greg Kroah-Hartman1-1/+1
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-16Linux 6.18.11v6.18.11Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20260213134708.885500854@linuxfoundation.org Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Brett Mastbergen <bmastbergen@ciq.com> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Barry K. Nathan <barryn@pobox.com> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Dileep Malepu <dileep.debian@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-09-02 17:16:32 +0300