linux.git/Makefile, branch v5.15.185

Linux 5.15.185

2025-06-04T12:38:08+00:00

Link: https://lore.kernel.org/r/20250602134258.769974467@linuxfoundation.org
Tested-by: Florian Fainelli 
Tested-by: Richard Narron 
Tested-by: Shuah Khan 
Tested-by: Mark Brown 
Tested-by: Hardik Garg 
Tested-by: Jon Hunter 
Signed-off-by: Greg Kroah-Hartman

kbuild: Disable -Wdefault-const-init-unsafe

2025-06-04T12:38:06+00:00

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

2025-05-22T12:08:28+00:00

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

Linux 5.15.183

2025-05-18T06:20:38+00:00

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

Linux 5.15.182

2025-05-09T07:39:43+00:00

Link: https://lore.kernel.org/r/20250507183759.048732653@linuxfoundation.org
Tested-by: Florian Fainelli 
Tested-by: Shuah Khan 
Link: https://lore.kernel.org/r/20250508112559.173535641@linuxfoundation.org
Tested-by: Linux Kernel Functional Testing 
Tested-by: Vijayendra Suman 
Tested-by: Jon Hunter 
Tested-by: Florian Fainelli 
Signed-off-by: Greg Kroah-Hartman

Linux 5.15.181

2025-05-02T05:44:40+00:00

Link: https://lore.kernel.org/r/20250429161123.119104857@linuxfoundation.org
Tested-by: Hardik Garg 
Tested-by: Jon Hunter 
Tested-by: Shuah Khan 
Tested-by: Linux Kernel Functional Testing 
Tested-by: Ron Economos 
Link: https://lore.kernel.org/r/20250501081459.064070563@linuxfoundation.org
Tested-by: Jon Hunter 
Tested-by: Mark Brown 
Tested-by: Hardik Garg 
Tested-by: Linux Kernel Functional Testing 
Signed-off-by: Greg Kroah-Hartman

kbuild: Add '-fno-builtin-wcslen'

2025-05-02T05:44:17+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 
[nathan: Resolve small conflict in older trees]
Signed-off-by: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman

Linux 5.15.180

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

Link: https://lore.kernel.org/r/20250408104826.319283234@linuxfoundation.org
Tested-by: Mark Brown 
Tested-by: Florian Fainelli 
Tested-by: SeongJae Park 
Tested-by: Vijayendra Suman 
Tested-by: Ron Economos 
Tested-by: Jon Hunter 
Tested-by: Linux Kernel Functional Testing 
Link: https://lore.kernel.org/r/20250409115832.538646489@linuxfoundation.org
Tested-by: Shuah Khan 
Tested-by: Florian Fainelli 
Tested-by: Mark Brown 
Tested-by: Linux Kernel Functional Testing 
Tested-by: Jon Hunter 
Signed-off-by: Greg Kroah-Hartman

Linux 5.15.179

2025-03-13T11:51:13+00:00

Link: https://lore.kernel.org/r/20250310170545.553361750@linuxfoundation.org
Tested-by: SeongJae Park 
Tested-by: Florian Fainelli 
Tested-by: Linux Kernel Functional Testing 
Tested-by: Shuah Khan 
Tested-by: Hardik Garg 
Link: https://lore.kernel.org/r/20250311135758.248271750@linuxfoundation.org
Tested-by: Ron Economos 
Tested-by: Vijayendra Suman 
Tested-by: Jon Hunter 
Tested-by: Florian Fainelli 
Tested-by: Linux Kernel Functional Testing 
Tested-by: Mark Brown 
Tested-by: Hardik Garg 
Signed-off-by: Greg Kroah-Hartman

kbuild: userprogs: use correct lld when linking through clang

2025-03-13T11:51:13+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 
[nathan: use cc-option for 6.6 and older, as those trees support back to
         clang-11]
Signed-off-by: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman