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

Linux 6.1.141

2025-06-04T12:40:26Z

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

kbuild: Disable -Wdefault-const-init-unsafe

2025-06-04T12:40:22Z

commit d0afcfeb9e3810ec89d1ffde1a0e36621bb75dca upstream. A new on by default warning in clang [1] aims to flags instances where const variables without static or thread local storage or const members in aggregate types are not initialized because it can lead to an indeterminate value. This is quite noisy for the kernel due to instances originating from header files such as: drivers/gpu/drm/i915/gt/intel_ring.h:62:2: error: default initialization of an object of type 'typeof (ring->size)' (aka 'const unsigned int') leaves the object uninitialized [-Werror,-Wdefault-const-init-var-unsafe] 62 | typecheck(typeof(ring->size), next); | ^ include/linux/typecheck.h:10:9: note: expanded from macro 'typecheck' 10 | ({ type __dummy; \ | ^ include/net/ip.h:478:14: error: default initialization of an object of type 'typeof (rt->dst.expires)' (aka 'const unsigned long') leaves the object uninitialized [-Werror,-Wdefault-const-init-var-unsafe] 478 | if (mtu && time_before(jiffies, rt->dst.expires)) | ^ include/linux/jiffies.h:138:26: note: expanded from macro 'time_before' 138 | #define time_before(a,b) time_after(b,a) | ^ include/linux/jiffies.h:128:3: note: expanded from macro 'time_after' 128 | (typecheck(unsigned long, a) && \ | ^ include/linux/typecheck.h:11:12: note: expanded from macro 'typecheck' 11 | typeof(x) __dummy2; \ | ^ include/linux/list.h:409:27: warning: default initialization of an object of type 'union (unnamed union at include/linux/list.h:409:27)' with const member leaves the object uninitialized [-Wdefault-const-init-field-unsafe] 409 | struct list_head *next = smp_load_acquire(&head->next); | ^ include/asm-generic/barrier.h:176:29: note: expanded from macro 'smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^ arch/arm64/include/asm/barrier.h:164:59: note: expanded from macro '__smp_load_acquire' 164 | union { __unqual_scalar_typeof(*p) __val; char __c[1]; } __u; \ | ^ include/linux/list.h:409:27: note: member '__val' declared 'const' here crypto/scatterwalk.c:66:22: error: default initialization of an object of type 'struct scatter_walk' with const member leaves the object uninitialized [-Werror,-Wdefault-const-init-field-unsafe] 66 | struct scatter_walk walk; | ^ include/crypto/algapi.h:112:15: note: member 'addr' declared 'const' here 112 | void *const addr; | ^ fs/hugetlbfs/inode.c:733:24: error: default initialization of an object of type 'struct vm_area_struct' with const member leaves the object uninitialized [-Werror,-Wdefault-const-init-field-unsafe] 733 | struct vm_area_struct pseudo_vma; | ^ include/linux/mm_types.h:803:20: note: member 'vm_flags' declared 'const' here 803 | const vm_flags_t vm_flags; | ^ Silencing the instances from typecheck.h is difficult because '= {}' is not available in older but supported compilers and '= {0}' would cause warnings about a literal 0 being treated as NULL. While it might be possible to come up with a local hack to silence the warning for clang-21+, it may not be worth it since -Wuninitialized will still trigger if an uninitialized const variable is actually used. In all audited cases of the "field" variant of the warning, the members are either not used in the particular call path, modified through other means such as memset() / memcpy() because the containing object is not const, or are within a union with other non-const members. Since this warning does not appear to have a high signal to noise ratio, just disable it. Cc: stable@vger.kernel.org Link: https://github.com/llvm/llvm-project/commit/576161cb6069e2c7656a8ef530727a0f4aefff30 [1] Reported-by: Linux Kernel Functional Testing Closes: https://lore.kernel.org/CA+G9fYuNjKcxFKS_MKPRuga32XbndkLGcY-PVuoSwzv6VWbY=w@mail.gmail.com/ Reported-by: Marcus Seyfarth Closes: https://github.com/ClangBuiltLinux/linux/issues/2088 Signed-off-by: Nathan Chancellor Signed-off-by: Masahiro Yamada [nathan: Apply change to Makefile instead of scripts/Makefile.extrawarn due to lack of e88ca24319e4 in older stable branches] Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman

Linux 6.1.140

2025-05-22T12:10:11Z

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

Linux 6.1.139

2025-05-18T06:21:27Z

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

Linux 6.1.138

2025-05-09T07:41:46Z

Link: https://lore.kernel.org/r/20250507183806.987408728@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Salvatore Bonaccorso Link: https://lore.kernel.org/r/20250508112609.711621924@linuxfoundation.org Tested-by: Peter Schneider Tested-by: Jon Hunter Tested-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman

Linux 6.1.137

2025-05-05T08:59:01Z

Signed-off-by: Greg Kroah-Hartman

Linux 6.1.136

2025-05-02T05:47:11Z

Link: https://lore.kernel.org/r/20250429161051.743239894@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Peter Schneider Tested-by: Hardik Garg Tested-by: Miguel Ojeda Tested-by: Shuah Khan Tested-by: Salvatore Bonaccorso Tested-by: Ron Economos Link: https://lore.kernel.org/r/20250501080849.930068482@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Mark Brown Tested-by: Hardik Garg Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman

Linux 6.1.135

2025-04-25T08:44:05Z

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

kbuild: Add '-fno-builtin-wcslen'

2025-04-25T08:44:00Z

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

Linux 6.1.134

2025-04-10T12:33:44Z

Link: https://lore.kernel.org/r/20250408104820.266892317@linuxfoundation.org Tested-by: Mark Brown Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Peter Schneider Tested-by: SeongJae Park Tested-by: Ron Economos Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Salvatore Bonaccorso Link: https://lore.kernel.org/r/20250409115832.610030955@linuxfoundation.org Tested-by: Shuah Khan 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