kernel/git/stable/linux.git/Makefile, branch linux-6.13.y

Linux 6.13.12

2025-04-20T08:18:30+00:00

Link: https://lore.kernel.org/r/20250417175111.386381660@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Salvatore Bonaccorso Tested-by: Peter Schneider Link: https://lore.kernel.org/r/20250418110411.049004302@linuxfoundation.org Tested-by: Mark Brown Tested-by: Jon Hunter Tested-by: Shuah Khan 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:18:11+00:00

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

Linux 6.13.11

2025-04-10T12:42:07+00:00

Link: https://lore.kernel.org/r/20250408104851.256868745@linuxfoundation.org Link: https://lore.kernel.org/r/20250408154123.083425991@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: Shuah Khan Link: https://lore.kernel.org/r/20250409115907.324928010@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.13.10

2025-04-07T08:09:36+00:00

Link: https://lore.kernel.org/r/20250403151622.273788569@linuxfoundation.org Tested-by: Salvatore Bonaccorso Tested-by: Pavel Machek (CIP) Tested-by: Peter Schneider Tested-by: Mark Brown Tested-by: Shuah Khan Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Justin M. Forbes Tested-by: Ron Economos Signed-off-by: Greg Kroah-Hartman

Linux 6.13.9

2025-03-28T21:04:59+00:00

Link: https://lore.kernel.org/r/20250325122149.058346343@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Miguel Ojeda Tested-by: Mark Brown Tested-by: Ron Economos Tested-by: Takeshi Ogasawara Tested-by: Jon Hunter Tested-by: Christian Heusel Tested-by: Peter Schneider Signed-off-by: Greg Kroah-Hartman

Linux 6.13.8

2025-03-22T19:56:59+00:00

Link: https://lore.kernel.org/r/20250319143027.685727358@linuxfoundation.org Tested-by: SeongJae Park Tested-by: Jon Hunter Tested-by: Salvatore Bonaccorso Tested-by: Ron Economos Tested-by: Miguel Ojeda Tested-by: Linux Kernel Functional Testing Tested-by: Mark Brown Tested-by: Luna Jernberg Tested-by: Hardik Garg Tested-by: Florian Fainelli Tested-by: Justin M. Forbes Tested-by: Peter Schneider Tested-by: Takeshi Ogasawara Signed-off-by: Greg Kroah-Hartman

Linux 6.13.7

2025-03-13T12:08:08+00:00

Link: https://lore.kernel.org/r/20250310170447.729440535@linuxfoundation.org Tested-by: SeongJae Park Tested-by: Florian Fainelli Tested-by: Salvatore Bonaccorso Tested-by: Luna Jernberg Tested-by: Ronald Warsow Tested-by: Ron Economos Tested-by: Jon Hunter Tested-By: Achill Gilgenast Tested-by: Takeshi Ogasawara Tested-by: Mark Brown Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Hardik Garg Link: https://lore.kernel.org/r/20250311144241.070217339@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Jon Hunter Tested-by: Florian Fainelli Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Luna Jernberg Tested-by: Linux Kernel Functional Testing Tested-by: Takeshi Ogasawara Tested-by: Mark Brown Tested-by: Justin M. Forbes Tested-by: Hardik Garg Signed-off-by: Greg Kroah-Hartman

kbuild: userprogs: use correct lld when linking through clang

2025-03-13T12:08:03+00:00

commit dfc1b168a8c4b376fa222b27b97c2c4ad4b786e1 upstream. The userprog infrastructure links objects files through $(CC). Either explicitly by manually calling $(CC) on multiple object files or implicitly by directly compiling a source file to an executable. The documentation at Documentation/kbuild/llvm.rst indicates that ld.lld would be used for linking if LLVM=1 is specified. However clang instead will use either a globally installed cross linker from $PATH called ${target}-ld or fall back to the system linker, which probably does not support crosslinking. For the normal kernel build this is not an issue because the linker is always executed directly, without the compiler being involved. Explicitly pass --ld-path to clang so $(LD) is respected. As clang 13.0.1 is required to build the kernel, this option is available. Fixes: 7f3a59db274c ("kbuild: add infrastructure to build userspace programs") Cc: stable@vger.kernel.org # needs wrapping in $(cc-option) for < 6.9 Signed-off-by: Thomas Weißschuh Reviewed-by: Nathan Chancellor Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman

Linux 6.13.6

2025-03-07T17:27:16+00:00

Link: https://lore.kernel.org/r/20250305174505.268725418@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Salvatore Bonaccorso Tested-by: SeongJae Park Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Takeshi Ogasawara Tested-by: Shuah Khan Tested-by: Hardik Garg Link: https://lore.kernel.org/r/20250306151416.469067667@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Mark Brown Tested-by: Florian Fainelli Tested-by: Peter Schneider Tested-by: Jon Hunter Tested-By: Achill Gilgenast Tested-by: Linux Kernel Functional Testing Tested-by: Takeshi Ogasawara Tested-by: Justin M. Forbes Signed-off-by: Greg Kroah-Hartman

Linux 6.13.5

2025-02-27T12:34:22+00:00

Link: https://lore.kernel.org/r/20250224142604.442289573@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: FLorian Fainelli Tested-by: Pavel Machek (CIP) Tested-by: Peter Schneider Tested-by: Shuah Khan Tested-by: Ron Economos Link: https://lore.kernel.org/r/20250225064750.953124108@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Takeshi Ogasawara Tested-by: Ronald Warsow Tested-by: Mark Brown Tested-by: Peter Schneider Tested-by: Slade Watkins Tested-by: Florian Fainelli Tested-by: Miguel Ojeda Tested-by: Linux Kernel Functional Testing Tested-By: Achill Gilgenast Tested-by: Luna Jernberg Tested-by: Pavel Machek (CIP) Tested-by: Salvatore Bonaccorso Tested-by: Justin M. Forbes Signed-off-by: Greg Kroah-Hartman