user/sven/linux.git/Makefile, branch v5.10.240

Linux 5.10.240

2025-07-17T16:28:01Z

Link: https://lore.kernel.org/r/20250715130810.830580412@linuxfoundation.org Tested-by: Brett A C Sheffield (Librecast) Link: https://lore.kernel.org/r/20250715150416.252033217@linuxfoundation.org Link: https://lore.kernel.org/r/20250715163613.640534312@linuxfoundation.org Tested-by: Dominique Martinet Tested-by: Jon Hunter Tested-by: Mark Brown Tested-by: Florian Fainelli Tested-by: Linux Kernel Functional Testing Tested-by: Brett A C Sheffield Signed-off-by: Greg Kroah-Hartman

Linux 5.10.239

2025-06-27T10:04:25Z

Link: https://lore.kernel.org/r/20250623130626.716971725@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Dominique Martinet Link: https://lore.kernel.org/r/20250624121412.352317604@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Dominique Martinet Tested-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

kbuild: userprogs: fix bitsize and target detection on clang

2025-06-27T10:04:11Z

commit 1b71c2fb04e7a713abc6edde4a412416ff3158f2 upstream. scripts/Makefile.clang was changed in the linked commit to move --target from KBUILD_CFLAGS to KBUILD_CPPFLAGS, as that generally has a broader scope. However that variable is not inspected by the userprogs logic, breaking cross compilation on clang. Use both variables to detect bitsize and target arguments for userprogs. Fixes: feb843a469fb ("kbuild: add $(CLANG_FLAGS) to KBUILD_CPPFLAGS") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh Reviewed-by: Nathan Chancellor Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman

kbuild: add $(CLANG_FLAGS) to KBUILD_CPPFLAGS

2025-06-27T10:04:10Z

commit feb843a469fb0ab00d2d23cfb9bcc379791011bb upstream. When preprocessing arch/*/kernel/vmlinux.lds.S, the target triple is not passed to $(CPP) because we add it only to KBUILD_{C,A}FLAGS. As a result, the linker script is preprocessed with predefined macros for the build host instead of the target. Assuming you use an x86 build machine, compare the following: $ clang -dM -E -x c /dev/null $ clang -dM -E -x c /dev/null -target aarch64-linux-gnu There is no actual problem presumably because our linker scripts do not rely on such predefined macros, but it is better to define correct ones. Move $(CLANG_FLAGS) to KBUILD_CPPFLAGS, so that all *.c, *.S, *.lds.S will be processed with the proper target triple. [Note] After the patch submission, we got an actual problem that needs this commit. (CBL issue 1859) Link: https://github.com/ClangBuiltLinux/linux/issues/1859 Reported-by: Tom Rini Signed-off-by: Masahiro Yamada Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman

Linux 5.10.238

2025-06-04T12:37:09Z

Link: https://lore.kernel.org/r/20250602134307.195171844@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman

kbuild: Disable -Wdefault-const-init-unsafe

2025-06-04T12:37:08Z

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 5.10.237

2025-05-02T05:41:22Z

Link: https://lore.kernel.org/r/20250429161107.848008295@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Dominique Martinet Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman

kbuild: Add '-fno-builtin-wcslen'

2025-05-02T05:41: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

Linux 5.10.236

2025-04-10T12:31:02Z

Link: https://lore.kernel.org/r/20250408104820.353768086@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20250409115831.755826974@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Mark Brown Tested-by: Dominique Martinet Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman

Linux 5.10.235

2025-03-13T11:47:45Z

Link: https://lore.kernel.org/r/20250311145758.343076290@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Pavel Machek (CIP) Tested-by: Dominique Martinet Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman