linux-stable.git/Makefile, branch v7.1.6

Linux 7.1.6

2026-08-03T09:26:04+00:00

Link: https://lore.kernel.org/r/20260730141444.267951807@linuxfoundation.org
Tested-by: Ronald Warsow 
Tested-by: Miguel Ojeda 
Tested-by: Brett A C Sheffield 
Tested-by: Salvatore Bonaccorso 
Tested-by: Peter Schneider 
Tested-by: Shuah Khan 
Tested-by: Justin M. Forbes 
Tested-by: Pavel Machek (CIP) 
Tested-by: Takeshi Ogasawara 
Tested-by: Markus Reichelt 
Tested-by: Benjamin Boortz 
Tested-by: Mark Brown 
Tested-by: Florian Fainelli 
Tested-by: Barry K. Nathan 
Tested-by: Ron Economos 
Tested-by: Jeffrin Jose T 
Signed-off-by: Greg Kroah-Hartman

rust: allow `clippy::unwrap_or_default` globally

2026-08-03T09:25:52+00:00

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 
Signed-off-by: Alexandre Courbot 
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 
Signed-off-by: Greg Kroah-Hartman

Linux 7.1.5

2026-07-24T14:21:27+00:00

Link: https://lore.kernel.org/r/20260721152552.646164743@linuxfoundation.org
Tested-by: Ronald Warsow 
Tested-by: Salvatore Bonaccorso 
Tested-by: Brett A C Sheffield 
Tested-by: Peter Schneider 
Tested-by: Ron Economos 
Tested-by: Takeshi Ogasawara 
Link: https://lore.kernel.org/r/20260722142947.085426486@linuxfoundation.org
Tested-by: Ronald Warsow 
Tested-by: Brett A C Sheffield 
Tested-by: Jeffrin Jose T 
Tested-by: Shuah Khan 
Tested-by: Pavel Machek (CIP) 
Tested-by: Florian Fainelli 
Tested-by: Justin M. Forbes 
Tested-by: Barry K. Nathan 
Tested-by: Takeshi Ogasawara 
Tested-by: Miguel Ojeda 
Tested-by: Mark Brown 
Tested-by: Peter Schneider 
Tested-by: Benjamin Boortz 
Signed-off-by: Greg Kroah-Hartman

Linux 7.1.4

2026-07-18T14:55:52+00:00

Link: https://lore.kernel.org/r/20260716133047.772246337@linuxfoundation.org
Tested-by: Ronald Warsow 
Tested-by: Brett A C Sheffield 
Tested-by: Florian Fainelli 
Tested-by: Justin M. Forbes 
Tested-by: Peter Schneider 
Tested-by: Salvatore Bonaccorso 
Tested-by: Miguel Ojeda 
Tested-by: Takeshi Ogasawara 
Tested-by: Ron Economos 
Tested-by: Shuah Khan 
Tested-by: Pavel Machek (CIP) 
Link: https://lore.kernel.org/r/20260717101912.682013354@linuxfoundation.org
Tested-by: Brett A C Sheffield 
Tested-by: Ronald Warsow 
Tested-by: Florian Fainelli 
Tested-by: Pavel Machek (CIP) 
Tested-by: Peter Schneider 
Tested-by: Takeshi Ogasawara 
Tested-by: Barry K. Nathan 
Tested-by: Mark Brown 
Tested-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

rust: Kbuild: set frame-pointer llvm module flag for CONFIG_FRAME_POINTER

2026-07-18T14:55:17+00:00

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 
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 
Signed-off-by: Greg Kroah-Hartman

Linux 7.1.3

2026-07-04T11:45:09+00:00

Link: https://lore.kernel.org/r/20260702155112.964534952@linuxfoundation.org
Tested-by: Ronald Warsow 
Tested-by: Brett A C Sheffield 
Tested-by: Salvatore Bonaccorso 
Tested-by: Peter Schneider 
Tested-by: Miguel Ojeda 
Link: https://lore.kernel.org/r/20260703072822.817328079@linuxfoundation.org
Tested-by: Pavel Machek (CIP) 
Tested-by: Brett A C Sheffield 
Tested-by: Ronald Warsow 
Tested-by: Dileep Malepu 
Tested-by: Mark Brown 
Tested-by: Takeshi Ogasawara 
Tested-by: Peter Schneider 
Tested-by: Ron Economos 
Tested-by: Miguel Ojeda 
Tested-by: Barry K. Nathan 
Signed-off-by: Greg Kroah-Hartman

gcov: use atomic counter updates to fix concurrent access crashes

2026-07-04T11:45:03+00:00

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 
Tested-by: Arnd Bergmann 
Tested-by: Peter Oberparleiter 
Reviewed-by: Peter Oberparleiter 
Cc: Masahiro Yamada 
Cc: Miguel Ojeda 
Cc: Mikhail Zaslonko 
Cc: Nathan Chancellor 
Cc: Pavel Tikhomirov 
Cc: Thomas Weißschuh 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

Linux 7.1.2

2026-06-27T10:08:18+00:00

Link: https://lore.kernel.org/r/20260625125613.243729608@linuxfoundation.org
Tested-by: Florian Fainelli 
Tested-by: Ronald Warsow 
Tested-by: Brett A C Sheffield 
Tested-by: Justin M. Forbes 
Tested-by: Peter Schneider 
Tested-by: Shuah Khan 
Tested-by: Ron Economos 
Tested-by: Miguel Ojeda 
Tested-by: Dileep Malepu 
Tested-by: Takeshi Ogasawara 
Tested-by: Mark Brown 
Tested-by: Jeffrin Jose T 
Signed-off-by: Greg Kroah-Hartman

Linux 7.1.1

2026-06-19T11:50:58+00:00

Link: https://lore.kernel.org/r/20260616145523.335696673@linuxfoundation.org
Tested-by: Brett A C Sheffield 
Tested-by: Salvatore Bonaccorso 
Tested-by: Barry K. Nathan 
Tested-by: Takeshi Ogasawara 
Tested-by: Miguel Ojeda 
Tested-by: Mark Brown 
Tested-by: Shuah Khan 
Tested-by: Peter Schneider 
Tested-by: Luna Jernberg 
Tested-by: Ron Economos 
Signed-off-by: Greg Kroah-Hartman

Linux 7.1

2026-06-14T14:58:38+00:00