user/sven/linux.git/Makefile, branch v6.12.27

Linux 6.12.27

2025-05-05T09:00:29Z

Signed-off-by: Greg Kroah-Hartman

Linux 6.12.26

2025-05-02T05:59:33Z

Link: https://lore.kernel.org/r/20250429161115.008747050@linuxfoundation.org Tested-by: Peter Schneider Tested-by: Shung-Hsi Yu Tested-by: Hardik Garg Tested-by: Jon Hunter Tested-by: Markus Reichelt Tested-by: Miguel Ojeda Tested-by: Shuah Khan Tested-by: Harshit Mogalapalli Tested-by: Salvatore Bonaccorso Tested-by: Ron Economos Tested-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

Linux 6.12.25

2025-04-25T08:48:08Z

Link: https://lore.kernel.org/r/20250423142617.120834124@linuxfoundation.org Tested-by: Peter Schneider Tested-by: Salvatore Bonaccorso Tested-by: Shuah Khan Tested-by: Mark Brown Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Tested-by: Florian Fainelli Tested-by: Markus Reichelt Tested-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

kbuild: Add '-fno-builtin-wcslen'

2025-04-25T08:48:04Z

commit 84ffc79bfbf70c779e60218563f2f3ad45288671 upstream. A recent optimization change in LLVM [1] aims to transform certain loop idioms into calls to strlen() or wcslen(). This change transforms the first while loop in UniStrcat() into a call to wcslen(), breaking the build when UniStrcat() gets inlined into alloc_path_with_tree_prefix(): ld.lld: error: undefined symbol: wcslen >>> referenced by nls_ucs2_utils.h:54 (fs/smb/client/../../nls/nls_ucs2_utils.h:54) >>> vmlinux.o:(alloc_path_with_tree_prefix) >>> referenced by nls_ucs2_utils.h:54 (fs/smb/client/../../nls/nls_ucs2_utils.h:54) >>> vmlinux.o:(alloc_path_with_tree_prefix) Disable this optimization with '-fno-builtin-wcslen', which prevents the compiler from assuming that wcslen() is available in the kernel's C library. [ More to the point - it's not that we couldn't implement wcslen(), it's that this isn't an optimization at all in the context of the kernel. Replacing a simple inlined loop with a function call to the same loop is just stupid and pointless if you don't have long strings and fancy libraries with vectorization support etc. For the regular 'strlen()' cases, we want the compiler to do this in order to handle the trivial case of constant strings. And we do have optimized versions of 'strlen()' on some architectures. But for wcslen? Just no. - Linus ] Cc: stable@vger.kernel.org Link: https://github.com/llvm/llvm-project/commit/9694844d7e36fd5e01011ab56b64f27b867aa72d [1] Signed-off-by: Nathan Chancellor Signed-off-by: Linus Torvalds [nathan: Resolve small conflict in older trees] Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman

rust: disable `clippy::needless_continue`

2025-04-25T08:47:49Z

commit 0866ee8e50f017731b80891294c0edd0f5fcd0a9 upstream. Starting with Rust 1.86.0, Clippy's `needless_continue` lint complains about the last statement of a loop [1], including cases like: while ... { match ... { ... if ... => { ... return ...; } _ => continue, } } as well as nested `match`es in a loop. One solution is changing `continue` for `()` [2], but arguably using `continue` shows the intent better when it is alone in an arm like that. Moreover, I am not sure we want to force people to try to find other ways to write the code either, in cases when that applies. In addition, the help text does not really apply in the new cases the lint has introduced, e.g. here one cannot simply "drop" the expression: warning: this `continue` expression is redundant --> rust/macros/helpers.rs:85:18 | 85 | _ => continue, | ^^^^^^^^ | = help: consider dropping the `continue` expression = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_continue = note: requested on the command line with `-W clippy::needless-continue` The examples in the documentation do not show a case like this, either, so the second "help" line does not help. In addition, locally disabling the lint is not possible with `expect`, since the behavior differs across versions. Using `allow` would be possible, but, even then, an extra line just for this is a bit too much, especially if there are other ways to satisfy the lint. Finally, the lint is still in the "pedantic" category and disabled by default by Clippy. Thus disable the lint, at least for the time being. Feedback was submitted to upstream Clippy, in case this can be improved or perhaps the lint split into several [3]. 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-clippy/pull/13891 [1] Link: https://lore.kernel.org/rust-for-linux/20250401221205.52381-1-ojeda@kernel.org/ [2] Link: https://github.com/rust-lang/rust-clippy/issues/14536 [3] Link: https://lore.kernel.org/r/20250403163805.67770-1-ojeda@kernel.org Reviewed-by: Alice Ryhl Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

Linux 6.12.24

2025-04-20T08:16:02Z

Link: https://lore.kernel.org/r/20250417175107.546547190@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Salvatore Bonaccorso Tested-by: Peter Schneider Tested-by: Markus Reichelt Tested-by: Shuah Khan Tested-by: Harshit Mogalapalli Link: https://lore.kernel.org/r/20250418110359.237869758@linuxfoundation.org Tested-by: Mark Brown Tested-by: Jon Hunter Tested-by: SeongJae Park Tested-by: Ron Economos Tested-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

kbuild: Add '-fno-builtin-wcslen'

2025-04-20T08:16:01Z

Linux 6.12.23

2025-04-10T12:39:41Z

Link: https://lore.kernel.org/r/20250408104845.675475678@linuxfoundation.org Tested-by: Markus Reichelt Link: https://lore.kernel.org/r/20250408154121.378213016@linuxfoundation.org Tested-by: Peter Schneider Tested-by: Florian Fainelli Tested-by: SeongJae Park Tested-by: Ron Economos Tested-by: Jon Hunter Tested-by: Salvatore Bonaccorso Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Link: https://lore.kernel.org/r/20250409115859.721906906@linuxfoundation.org Tested-by: Miguel Ojeda Tested-by: Mark Brown Tested-by: Florian Fainelli Tested-by: Peter Schneider Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman

Linux 6.12.22

2025-04-07T08:08:37Z

Link: https://lore.kernel.org/r/20250403151622.055059925@linuxfoundation.org Tested-by: Markus Reichelt Tested-by: Salvatore Bonaccorso Tested-by: Peter Schneider Tested-by: Florian Fainelli Tested-by: Mark Brown Tested-by: Shuah Khan Tested-by: Jon Hunter Tested-by: Ron Economos Tested-by: Harshit Mogalapalli Signed-off-by: Greg Kroah-Hartman

Linux 6.12.21

2025-03-28T21:03:33Z

Link: https://lore.kernel.org/r/20250325122149.207086105@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Miguel Ojeda Tested-by: Pavel Machek (CIP) Link: https://lore.kernel.org/r/20250326154546.724728617@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Hardik Garg Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Mark Brown Tested-by: Jon Hunter Tested-by: Harshit Mogalapalli Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Tested-by: Harshit Mogalapalli Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Signed-off-by: Greg Kroah-Hartman