5.10 kernel series fails to build on newer toolchain: FAILED unresolved symbol filp_close
For some odd reason 5.10 kernel series doesn't compile with a newer toolchain since 2025-02-09:
2025-02-09T17:32:07.7991299Z GEN .version 2025-02-09T17:32:07.8270062Z CHK include/generated/compile.h 2025-02-09T17:32:07.8540777Z LD vmlinux.o 2025-02-09T17:32:11.7210899Z MODPOST vmlinux.symvers 2025-02-09T17:32:12.0869599Z MODINFO modules.builtin.modinfo 2025-02-09T17:32:12.1403022Z GEN modules.builtin 2025-02-09T17:32:12.1475659Z LD .tmp_vmlinux.btf 2025-02-09T17:32:19.6117204Z BTF .btf.vmlinux.bin.o 2025-02-09T17:32:31.2916650Z LD .tmp_vmlinux.kallsyms1 2025-02-09T17:32:34.8731104Z KSYMS .tmp_vmlinux.kallsyms1.S 2025-02-09T17:32:35.4910608Z AS .tmp_vmlinux.kallsyms1.o 2025-02-09T17:32:35.9662538Z LD .tmp_vmlinux.kallsyms2 2025-02-09T17:32:39.2595984Z KSYMS .tmp_vmlinux.kallsyms2.S 2025-02-09T17:32:39.8802028Z AS .tmp_vmlinux.kallsyms2.o 2025-02-09T17:32:40.3659440Z LD vmlinux 2025-02-09T17:32:48.0031558Z BTFIDS vmlinux 2025-02-09T17:32:48.0143553Z FAILED unresolved symbol filp_close 2025-02-09T17:32:48.5019928Z make: *** [Makefile:1207: vmlinux] Error 255 2025-02-09T17:32:48.5061241Z ==> ERROR: A failure occurred in build().
5.10.234 built fine couple of days ago with the older one. There were slight changes made. 5.4 and 5.15 still compile.
Wonder what might be missing here ...
On Fri, Mar 14, 2025 at 08:18:27AM +0700, Philip Müller wrote:
For some odd reason 5.10 kernel series doesn't compile with a newer toolchain since 2025-02-09:
2025-02-09T17:32:07.7991299Z GEN .version 2025-02-09T17:32:07.8270062Z CHK include/generated/compile.h 2025-02-09T17:32:07.8540777Z LD vmlinux.o 2025-02-09T17:32:11.7210899Z MODPOST vmlinux.symvers 2025-02-09T17:32:12.0869599Z MODINFO modules.builtin.modinfo 2025-02-09T17:32:12.1403022Z GEN modules.builtin 2025-02-09T17:32:12.1475659Z LD .tmp_vmlinux.btf 2025-02-09T17:32:19.6117204Z BTF .btf.vmlinux.bin.o 2025-02-09T17:32:31.2916650Z LD .tmp_vmlinux.kallsyms1 2025-02-09T17:32:34.8731104Z KSYMS .tmp_vmlinux.kallsyms1.S 2025-02-09T17:32:35.4910608Z AS .tmp_vmlinux.kallsyms1.o 2025-02-09T17:32:35.9662538Z LD .tmp_vmlinux.kallsyms2 2025-02-09T17:32:39.2595984Z KSYMS .tmp_vmlinux.kallsyms2.S 2025-02-09T17:32:39.8802028Z AS .tmp_vmlinux.kallsyms2.o 2025-02-09T17:32:40.3659440Z LD vmlinux 2025-02-09T17:32:48.0031558Z BTFIDS vmlinux 2025-02-09T17:32:48.0143553Z FAILED unresolved symbol filp_close 2025-02-09T17:32:48.5019928Z make: *** [Makefile:1207: vmlinux] Error 255 2025-02-09T17:32:48.5061241Z ==> ERROR: A failure occurred in build().
5.10.234 built fine couple of days ago with the older one. There were slight changes made. 5.4 and 5.15 still compile.
Wonder what might be missing here ...
Can you bisect down to the offending commit?
And I think I saw kernelci hit this as well, but I don't have an answer for it...
greg k-h
On 14/3/25 12:39, Greg Kroah-Hartman wrote:
Can you bisect down to the offending commit?
And I think I saw kernelci hit this as well, but I don't have an answer for it...
The same kernel compiles fine with the older toolchain. No changes were made to config nor patch-set when we tried to recompile the 5.10.234 kernel with the newer toolchain. 5.10.235 fails similar to 5.10.234 on the same toolchain.
So maybe a commit is missing, which is present in either 5.4 or 5.15 series.
Hello,
On Fri, 14 Mar 2025 16:19:13 +0700, Philip Müller wrote:
On 14/3/25 12:39, Greg Kroah-Hartman wrote:
Can you bisect down to the offending commit?
And I think I saw kernelci hit this as well, but I don't have an answer for it...
The same kernel compiles fine with the older toolchain. No changes were made to config nor patch-set when we tried to recompile the 5.10.234 kernel with the newer toolchain. 5.10.235 fails similar to 5.10.234 on the same toolchain.
So maybe a commit is missing, which is present in either 5.4 or 5.15 series.
KernelCI is now reporting a pass on the stable-rc build (5.10.236-rc1), though I was not able to spot exactly what fixed this.
Best, Laura
On Thu, Mar 20, 2025 at 12:28:06PM +0100, Laura Nao wrote:
Hello,
On Fri, 14 Mar 2025 16:19:13 +0700, Philip Müller wrote:
On 14/3/25 12:39, Greg Kroah-Hartman wrote:
Can you bisect down to the offending commit?
And I think I saw kernelci hit this as well, but I don't have an answer for it...
The same kernel compiles fine with the older toolchain. No changes were made to config nor patch-set when we tried to recompile the 5.10.234 kernel with the newer toolchain. 5.10.235 fails similar to 5.10.234 on the same toolchain.
So maybe a commit is missing, which is present in either 5.4 or 5.15 series.
KernelCI is now reporting a pass on the stable-rc build (5.10.236-rc1), though I was not able to spot exactly what fixed this.
That's good to know, thanks!
Yes, I can confirm that with the current stable-queue patches on top of 5.10.235 it compiles. I only had to not apply the following patch
ASoC: Intel: sof_sdw: Add support for Fatcat board with BT offload enabled in PTL platform
due to this compile error it created:
2025-03-28T08:55:34.9654713Z CC net/unix/sysctl_net_unix.o 2025-03-28T08:55:35.0056914Z sound/soc/intel/boards/sof_sdw.c:243:41: error: ‘SOC_SDW_PCH_DMIC’ undeclared here (not in a function); did you mean ‘SOF_SDW_PCH_DMIC’? 2025-03-28T08:55:35.0058317Z 243 | .driver_data = (void *)(SOC_SDW_PCH_DMIC | 2025-03-28T08:55:35.0059209Z | ^~~~~~~~~~~~~~~~ 2025-03-28T08:55:35.0060110Z | SOF_SDW_PCH_DMIC 2025-03-28T08:55:35.0578564Z sound/soc/intel/boards/sof_sdw.c:244:41: error: implicit declaration of function ‘SOF_BT_OFFLOAD_SSP’ [-Werror=implicit-function-declaration] 2025-03-28T08:55:35.0580183Z 244 | SOF_BT_OFFLOAD_SSP(2) | 2025-03-28T08:55:35.0581143Z | ^~~~~~~~~~~~~~~~~~ 2025-03-28T08:55:35.1499457Z sound/soc/intel/boards/sof_sdw.c:245:41: error: ‘SOF_SSP_BT_OFFLOAD_PRESENT’ undeclared here (not in a function) 2025-03-28T08:55:35.1500818Z 245 | SOF_SSP_BT_OFFLOAD_PRESENT), 2025-03-28T08:55:35.1501765Z | ^~~~~~~~~~~~~~~~~~~~~~~~~~ 2025-03-28T08:55:35.2672363Z cc1: some warnings being treated as errors 2025-03-28T08:55:35.2740103Z make[4]: *** [scripts/Makefile.build:286: sound/soc/intel/boards/sof_sdw.o] Error 1 2025-03-28T08:55:35.2767794Z make[3]: *** [scripts/Makefile.build:503: sound/soc/intel/boards] Error 2 2025-03-28T08:55:35.2773462Z make[2]: *** [scripts/Makefile.build:503: sound/soc/intel] Error 2 2025-03-28T08:55:35.2801723Z make[1]: *** [scripts/Makefile.build:503: sound/soc] Error 2 2025-03-28T08:55:35.2802890Z make: *** [Makefile:1837: sound] Error 2
On 3/20/25 07:28, Laura Nao wrote:
Hello,
On Fri, 14 Mar 2025 16:19:13 +0700, Philip Müller wrote:
On 14/3/25 12:39, Greg Kroah-Hartman wrote:
Can you bisect down to the offending commit?
And I think I saw kernelci hit this as well, but I don't have an answer for it...
The same kernel compiles fine with the older toolchain. No changes were made to config nor patch-set when we tried to recompile the 5.10.234 kernel with the newer toolchain. 5.10.235 fails similar to 5.10.234 on the same toolchain.
So maybe a commit is missing, which is present in either 5.4 or 5.15 series.
KernelCI is now reporting a pass on the stable-rc build (5.10.236-rc1), though I was not able to spot exactly what fixed this.
Best, Laura
On Fri, Mar 28, 2025 at 07:06:10AM -0400, Philip Müller wrote:
Yes, I can confirm that with the current stable-queue patches on top of 5.10.235 it compiles. I only had to not apply the following patch
ASoC: Intel: sof_sdw: Add support for Fatcat board with BT offload enabled in PTL platform
I've dropped this commit from the queue now, thanks.
greg k-h
On 4/1/25 11:17, Greg KH wrote:
On Fri, Mar 28, 2025 at 07:06:10AM -0400, Philip Müller wrote:
Yes, I can confirm that with the current stable-queue patches on top of 5.10.235 it compiles. I only had to not apply the following patch
ASoC: Intel: sof_sdw: Add support for Fatcat board with BT offload enabled in PTL platform
I've dropped this commit from the queue now, thanks.
greg k-h
Somehow the issue came back with 5.10.238 ...
On Thu, Jun 05, 2025 at 09:44:49AM +0200, Philip Müller wrote:
On 4/1/25 11:17, Greg KH wrote:
On Fri, Mar 28, 2025 at 07:06:10AM -0400, Philip Müller wrote:
Yes, I can confirm that with the current stable-queue patches on top of 5.10.235 it compiles. I only had to not apply the following patch
ASoC: Intel: sof_sdw: Add support for Fatcat board with BT offload enabled in PTL platform
I've dropped this commit from the queue now, thanks.
greg k-h
Somehow the issue came back with 5.10.238 ...
I have no context here, sorry...
On 6/5/25 10:46, Greg KH wrote:
I have no context here, sorry...
So basically, starting with GCC 15.1 the kernel series doesn't compile again and errors out with: FAILED unresolved symbol filp_close. I tested now v5.10.237 as well, which failed similar to v5.10.238.
There are some Debian reports out there:
https://linux.debian.bugs.dist.narkive.com/2JKeaFga/bug-1104662-failed-unres... https://www.mail-archive.com/debian-kernel@lists.debian.org/msg142397.html
And I also found this one:
https://lists-ec2.96boards.org/archives/list/linux-stable-mirror@lists.linar...
For GCC 14.1 I had to add the gnu 11 patch, which was discussed already. Also 5.4 and 5.15 still compile with the newer toolchain ...
On Sun, Jun 08, 2025 at 08:27:35AM +0200, Philip Müller wrote:
On 6/5/25 10:46, Greg KH wrote:
I have no context here, sorry...
So basically, starting with GCC 15.1 the kernel series doesn't compile again and errors out with: FAILED unresolved symbol filp_close. I tested now v5.10.237 as well, which failed similar to v5.10.238.
There are some Debian reports out there:
https://linux.debian.bugs.dist.narkive.com/2JKeaFga/bug-1104662-failed-unres... https://www.mail-archive.com/debian-kernel@lists.debian.org/msg142397.html
And I also found this one:
https://lists-ec2.96boards.org/archives/list/linux-stable-mirror@lists.linar...
For GCC 14.1 I had to add the gnu 11 patch, which was discussed already. Also 5.4 and 5.15 still compile with the newer toolchain ...
-- Best, Philip
Commit b3bee1e7c3f2b1b77182302c7b2131c804175870 x86/boot: Compile boot code with -std=gnu11 too fixed a build failure when compiling with GCC 15. The same change is required for linux-5.10.236.
Signed-off-by: Chris Clayton chris2553@googlemail.com Modified-by: Philip Mueller philm@manjaro.org Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
diff -rup linux-5.10.236.orig/arch/x86/Makefile linux-5.10.236/arch/x86/Makefile --- linux-5.10.236.orig/arch/x86/Makefile 2025-04-10 13:37:44.000000000 +0100 +++ linux-5.10.236/arch/x86/Makefile 2025-04-26 19:37:38.294386968 +0100 @@ -31,7 +31,7 @@ endif CODE16GCC_CFLAGS := -m32 -Wa,$(srctree)/arch/x86/boot/code16gcc.h M16_CFLAGS := $(call cc-option, -m16, $(CODE16GCC_CFLAGS)) -REALMODE_CFLAGS := $(M16_CFLAGS) -g -Os -DDISABLE_BRANCH_PROFILING -D__DISABLE_EXPORTS \ +REALMODE_CFLAGS := -std=gnu11 $(M16_CFLAGS) -g -Os -DDISABLE_BRANCH_PROFILING -D__DISABLE_EXPORTS \ -Wall -Wstrict-prototypes -march=i386 -mregparm=3 \ -fno-strict-aliasing -fomit-frame-pointer -fno-pic \ -mno-mmx -mno-sse $(call cc-option,-fcf-protection=none)
Can you resend this in a format we can apply it in?
Also for the newer kernels, this was only backported to 6.6.y, so anything older than that should need this, right?
thanks,
greg k-h
On Thu, Jun 19, 2025 at 10:34:52AM +0200, Philip Müller wrote:
On 6/17/25 16:05, Greg KH wrote:
Also for the newer kernels, this was only backported to 6.6.y, so anything older than that should need this, right?
Well, yes. The patches I applied on my end are attached.
-- Best, Philip
Commit b3bee1e7c3f2b1b77182302c7b2131c804175870 x86/boot: Compile boot code with -std=gnu11 too fixed a build failure when compiling with GCC 15. The same change is required for linux-5.4.292.
Something went wrong with the whitespace here :(
Signed-off-by: Chris Clayton chris2553@googlemail.com Modified-by: Philip Mueller philm@manjaro.org
You lost the original authorship and signed-off-by lines :(
Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
This isn't needed either.
Can you try again?
thanks,
greg k-h
On Tue, Jun 24, 2025 at 09:05:31AM +0200, Philip Müller wrote:
On 6/5/25 10:46, Greg KH wrote:
I have no context here, sorry...
Seems with 5.10.239-rc1 it compiles again just fine ...
We've been seeing this issue[1] since 5.10.244 (specifically commit b039655d31a1 ("genirq: Provide new interfaces for affinity hints")), and still in 5.10.245.
Given that this has apparently come up before, and I don't see any likely cause looking at that diff, I suppose it's probably some build issue in 5.10 that can be triggered by innocent diffs, and so is liable to keep fixing and breaking itself until somebody figure out the root cause…
[1]: https://github.com/NixOS/nixpkgs/pull/448034#issuecomment-3364278085
On Sun, 26 Oct 2025, Alyssa Ross wrote:
On Tue, Jun 24, 2025 at 09:05:31AM +0200, Philip Müller wrote:
On 6/5/25 10:46, Greg KH wrote:
I have no context here, sorry...
Seems with 5.10.239-rc1 it compiles again just fine ...
We've been seeing this issue[1] since 5.10.244 (specifically commit b039655d31a1 ("genirq: Provide new interfaces for affinity hints")), and still in 5.10.245.
Given that this has apparently come up before, and I don't see any likely cause looking at that diff, I suppose it's probably some build issue in 5.10 that can be triggered by innocent diffs, and so is liable to keep fixing and breaking itself until somebody figure out the root cause…
I have analyzed the issue, and it seems like never versions of GCC will agressively inline both in compile and linktime. I'm not sure if this is fixed properly in master, I would assume its fixed by adding enough code into BTF exposed functions so that they not optimized away anymore.
I can "fix" this locally via: CONFIG_DEBUG_INFO_BTF=n
or
diff --git a/fs/Makefile b/fs/Makefile index c660ce28f149..6fbaccbae1d9 100644 --- a/fs/Makefile +++ b/fs/Makefile @@ -6,6 +6,10 @@ # Rewritten to use lists instead of if-statements. #
+# Prevent agressive link-time inlining of BTF symbols +# Prevent GCC 15 IPA from removing filp_close symbol needed for BTF +CFLAGS_open.o = -fno-inline -fno-ipa-sra +
or by removing line below.
linux-stable$ git grep filp_close kernel/trace kernel/trace/bpf_trace.c:BTF_ID(func, filp_close)
Last seems like the simplest option, but would cause regressions for BPF programs I presume. GCC 15+ does not seem to adhere to __noinline, at least not for this issue.
linux-stable-mirror@lists.linaro.org
-
Alyssa Ross -
David Nyström -
Greg KH -
Greg Kroah-Hartman
-
Laura Nao -
Philip Müller