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

Linux 7.0.13

2026-06-19T11:48:13+00:00

Link: https://lore.kernel.org/r/20260616145109.744539446@linuxfoundation.org
Tested-by: Ronald Warsow 
Tested-by: Brett A C Sheffield 
Tested-by: Salvatore Bonaccorso 
Tested-by: Shung-Hsi Yu 
Tested-by: Miguel Ojeda 
Tested-by: Mark Brown 
Tested-by: Shuah Khan 
Tested-by: Peter Schneider 
Tested-by: Luna Jernberg 
Tested-by: Ron Economos 
Tested-by: Pavel Machek (CIP) 
Signed-off-by: Greg Kroah-Hartman

rust: kasan/kbuild: fix rustc-option when cross-compiling

2026-06-19T11:47:57+00:00

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 
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 

  This matches other variables. - Miguel ]
Signed-off-by: Miguel Ojeda

Linux 7.0.12

2026-06-09T10:32:51+00:00

Link: https://lore.kernel.org/r/20260607095728.031258202@linuxfoundation.org
Tested-by: Ronald Warsow 
Tested-by: Takeshi Ogasawara 
Tested-by: Jeffrin Jose T 
Tested-by: Miguel Ojeda 
Tested-by: Pavel Machek (CIP) 
Tested-by: Peter Schneider 
Tested-by: Ron Economos 
Tested-by: Florian Fainelli 
Tested-by: Mark Brown 
Tested-by: Dileep Malepu 
Tested-by: Salvatore Bonaccorso 
Tested-by: Justin M. Forbes 
Tested-by: Barry K. Nathan 
Signed-off-by: Greg Kroah-Hartman

Linux 7.0.11

2026-06-01T15:54:55+00:00

Link: https://lore.kernel.org/r/20260528194646.819809818@linuxfoundation.org
Tested-by: Ronald Warsow 
Tested-by: Takeshi Ogasawara 
Tested-by: Ron Economos 
Tested-by: Luna Jernberg 
Tested-by: Miguel Ojeda 
Tested-by: Brett A C Sheffield 
Tested-by: Salvatore Bonaccorso 
Tested-by: Pavel Machek (CIP) 
Tested-by: Jeffrin Jose T 
Tested-by: Peter Schneider 
Tested-by: Masoud Aghasi 
Tested-by: Florian Fainelli 
Tested-by: Mark Brown 
Tested-by: Markus Reichelt 
Tested-by: Barry K. Nathan 
Tested-by: Kalden Elphick 
Signed-off-by: Greg Kroah-Hartman

Linux 7.0.10

2026-05-23T11:09:44+00:00

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

kbuild: Never respect CONFIG_WERROR / W=e to fixdep

2026-05-23T11:09:25+00:00

[ 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 
Reviewed-by: Nathan Chancellor 
Link: https://patch.msgid.link/20260422-kbuild-scripts-basic-werror-v1-1-8c6912ff22e0@weissschuh.net
Signed-off-by: Nicolas Schier 
Signed-off-by: Sasha Levin

Linux 7.0.9

2026-05-17T15:16:34+00:00

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

Linux 7.0.8

2026-05-15T12:53:54+00:00

Signed-off-by: Greg Kroah-Hartman

Linux 7.0.7

2026-05-14T13:31:20+00:00

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

rust: allow `clippy::collapsible_if` globally

2026-05-14T13:31:06+00:00

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 
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 
Link: https://patch.msgid.link/20260426144201.227108-2-ojeda@kernel.org
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman