The arm64 defconfig builds failed on today's Linux next tag next-20240223.
arm64:
defconfig: gcc-13 - Failed
defconfig: clang-17 - Failed
Build log:
------
2024/02/23 08:03:02 socat-internal[923] W waitpid(-1, {}, WNOHANG): no
child has exited
2024/02/23 08:03:02 socat-internal[923] W waitpid(-1, {}, WNOHANG): no
child has exited
2024/02/23 08:03:02 socat-external[919] W waitpid(-1, {}, WNOHANG): no
child has exited
arch/arm64/boot/dts/freescale/mba8xx.dtsi:233.20-249.4: Warning
(interrupt_provider): /bus@5a000000/i2c@5a810000/gpio@70: Missing
'#interrupt-cells' in interrupt provider
arch/arm64/boot/dts/freescale/imx8dxp-tqma8xdp-mba8xx.dtb: Warning
(interrupt_map): Failed prerequisite 'interrupt_provider'
2024/02/23 08:03:04 socat-internal[923] W waitpid(-1, {}, WNOHANG): no
child has exited
2024/02/23 08:03:06 socat-external[919] W waitpid(-1, {}, WNOHANG): no
child has exited
In file included from arch/arm64/include/asm/lse.h:5,
from arch/arm64/include/asm/cmpxchg.h:14,
from arch/arm64/include/asm/atomic.h:16,
from include/linux/atomic.h:7,
from include/asm-generic/bitops/atomic.h:5,
from arch/arm64/include/asm/bitops.h:25,
from include/linux/bitops.h:68,
from arch/arm64/include/asm/memory.h:209,
from arch/arm64/include/asm/page.h:46,
from include/vdso/datapage.h:22,
from lib/vdso/gettimeofday.c:5,
from <command-line>:
arch/arm64/include/asm/atomic_ll_sc.h:298:9: error: unknown type name 'u128'
298 | u128 full;
| ^~~~
arch/arm64/include/asm/atomic_ll_sc.h:305:24: error: unknown type name 'u128'
305 | static __always_inline u128
\
|
Reported-by: Linux Kernel Functional Testing <[email protected]>
Steps to reproduce:
$ tuxmake --runtime podman --target-arch arm64 --toolchain gcc-13
--kconfig defconfig
Links:
- https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20240223/testrun/22811036/suite/build/test/gcc-13-defconfig/details/
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2cl8paYnjzOljEurAWeMOWjikoy/
--
Linaro LKFT
https://lkft.linaro.org
On Fri, Feb 23, 2024, at 10:10, Naresh Kamboju wrote:
> In file included from arch/arm64/include/asm/lse.h:5,
> from arch/arm64/include/asm/cmpxchg.h:14,
> from arch/arm64/include/asm/atomic.h:16,
> from include/linux/atomic.h:7,
> from include/asm-generic/bitops/atomic.h:5,
> from arch/arm64/include/asm/bitops.h:25,
> from include/linux/bitops.h:68,
> from arch/arm64/include/asm/memory.h:209,
> from arch/arm64/include/asm/page.h:46,
> from include/vdso/datapage.h:22,
> from lib/vdso/gettimeofday.c:5,
>
> from <command-line>:
> arch/arm64/include/asm/atomic_ll_sc.h:298:9: error: unknown type name 'u128'
> 298 | u128 full;
> | ^~~~
> arch/arm64/include/asm/atomic_ll_sc.h:305:24: error: unknown type name 'u128'
> 305 | static __always_inline u128
The problem here is the separation of vdso/*.h headers and
linux/*.h headers.
Commit a0d2fcd62ac2 ("vdso/ARM: Make union vdso_data_store
available for all architectures") introduced a reference to
the asm/page.h in include/vdso/datapage.h, but this is outside
of the vdso/*.h namespace and doesn't work in the compat vdso.
I think it is only needed because of the PAGE_SIZE macro,
so that constant needs to come from somewhere else.
I have an older patch that I never merged to unify the
page size configuration in Kconfig, and could try to
dig that out if nobody has a better idea. If we do that,
we could introduce a CONFIG_PAGE_SIZE.
Arnd
Hi Arnd,
On Fri, 23 Feb 2024 at 14:56, Arnd Bergmann <[email protected]> wrote:
>
> On Fri, Feb 23, 2024, at 10:10, Naresh Kamboju wrote:
> > In file included from arch/arm64/include/asm/lse.h:5,
> > from arch/arm64/include/asm/cmpxchg.h:14,
> > from arch/arm64/include/asm/atomic.h:16,
> > from include/linux/atomic.h:7,
> > from include/asm-generic/bitops/atomic.h:5,
> > from arch/arm64/include/asm/bitops.h:25,
> > from include/linux/bitops.h:68,
> > from arch/arm64/include/asm/memory.h:209,
> > from arch/arm64/include/asm/page.h:46,
> > from include/vdso/datapage.h:22,
> > from lib/vdso/gettimeofday.c:5,
> >
> > from <command-line>:
> > arch/arm64/include/asm/atomic_ll_sc.h:298:9: error: unknown type name 'u128'
> > 298 | u128 full;
> > | ^~~~
> > arch/arm64/include/asm/atomic_ll_sc.h:305:24: error: unknown type name 'u128'
> > 305 | static __always_inline u128
>
> The problem here is the separation of vdso/*.h headers and
> linux/*.h headers.
>
> Commit a0d2fcd62ac2 ("vdso/ARM: Make union vdso_data_store
> available for all architectures") introduced a reference to
> the asm/page.h in include/vdso/datapage.h, but this is outside
> of the vdso/*.h namespace and doesn't work in the compat vdso.
>
> I think it is only needed because of the PAGE_SIZE macro,
> so that constant needs to come from somewhere else.
>
> I have an older patch that I never merged to unify the
> page size configuration in Kconfig, and could try to
> dig that out if nobody has a better idea. If we do that,
> we could introduce a CONFIG_PAGE_SIZE.
The 16K and 64k page size builds pass.
>
> Arnd
On Mon, Feb 26, 2024, at 16:33, Naresh Kamboju wrote:
> On Fri, 23 Feb 2024 at 14:56, Arnd Bergmann <[email protected]> wrote:
>> I have an older patch that I never merged to unify the
>> page size configuration in Kconfig, and could try to
>> dig that out if nobody has a better idea. If we do that,
>> we could introduce a CONFIG_PAGE_SIZE.
>
> The 16K and 64k page size builds pass.
Those have compat mode disabled on arm64 for historic reasons.
We should probably fix that, but that is a different problem.
Arnd
"Arnd Bergmann" <[email protected]> writes:
> On Fri, Feb 23, 2024, at 10:10, Naresh Kamboju wrote:
>> In file included from arch/arm64/include/asm/lse.h:5,
>> from arch/arm64/include/asm/cmpxchg.h:14,
>> from arch/arm64/include/asm/atomic.h:16,
>> from include/linux/atomic.h:7,
>> from include/asm-generic/bitops/atomic.h:5,
>> from arch/arm64/include/asm/bitops.h:25,
>> from include/linux/bitops.h:68,
>> from arch/arm64/include/asm/memory.h:209,
>> from arch/arm64/include/asm/page.h:46,
>> from include/vdso/datapage.h:22,
>> from lib/vdso/gettimeofday.c:5,
>>
>> from <command-line>:
>> arch/arm64/include/asm/atomic_ll_sc.h:298:9: error: unknown type name 'u128'
>> 298 | u128 full;
>> | ^~~~
>> arch/arm64/include/asm/atomic_ll_sc.h:305:24: error: unknown type name 'u128'
>> 305 | static __always_inline u128
>
> The problem here is the separation of vdso/*.h headers and
> linux/*.h headers.
>
> Commit a0d2fcd62ac2 ("vdso/ARM: Make union vdso_data_store
> available for all architectures") introduced a reference to
> the asm/page.h in include/vdso/datapage.h, but this is outside
> of the vdso/*.h namespace and doesn't work in the compat vdso.
But the asm namespace works for the vdso namespace. Only linux headers
do not work, or am I wrong?
> I think it is only needed because of the PAGE_SIZE macro,
> so that constant needs to come from somewhere else.
Yes.
> I have an older patch that I never merged to unify the
> page size configuration in Kconfig, and could try to
> dig that out if nobody has a better idea. If we do that,
> we could introduce a CONFIG_PAGE_SIZE.
PAGE_SIZE is defined in asm/page-def.h for arm64. So this could be a
fast fix (tested with clang-14):
---8<----
--- a/include/vdso/datapage.h
+++ b/include/vdso/datapage.h
@@ -19,7 +19,11 @@
#include <vdso/time32.h>
#include <vdso/time64.h>
+#ifdef CONFIG_ARM64
+#include <asm/page-def.h>
+#else
#include <asm/page.h>
+#endif
#ifdef CONFIG_ARCH_HAS_VDSO_DATA
#include <asm/vdso/data.h>
---8<---
Thanks,
Anna-Maria
"Arnd Bergmann" <[email protected]> writes:
> On Mon, Feb 26, 2024, at 17:00, Anna-Maria Behnsen wrote:
>> "Arnd Bergmann" <[email protected]> writes:
>>> Commit a0d2fcd62ac2 ("vdso/ARM: Make union vdso_data_store
>>> available for all architectures") introduced a reference to
>>> the asm/page.h in include/vdso/datapage.h, but this is outside
>>> of the vdso/*.h namespace and doesn't work in the compat vdso.
>>
>> But the asm namespace works for the vdso namespace. Only linux headers
>> do not work, or am I wrong?
>
> The vdso namespace was added to have something that works for
> userspace code in both compat 32-bit mode and native (32 or
> 64) bit mode, while anything outside of include/vdso may not
> work here.
>
>> PAGE_SIZE is defined in asm/page-def.h for arm64. So this could be a
>> fast fix (tested with clang-14):
>>
>> ---8<----
>> --- a/include/vdso/datapage.h
>> +++ b/include/vdso/datapage.h
>> @@ -19,7 +19,11 @@
>> #include <vdso/time32.h>
>> #include <vdso/time64.h>
>>
>> +#ifdef CONFIG_ARM64
>> +#include <asm/page-def.h>
>> +#else
>> #include <asm/page.h>
>> +#endif
>>
>> #ifdef CONFIG_ARCH_HAS_VDSO_DATA
>> #include <asm/vdso/data.h>
>> ---8<---
>
> I've sent my own patch now, which is something we probably want
> anyway, but is obviously much more invasive thank your four-line
> patch.
Yes I saw it already.
> Maybe we can put your quick fix in the tip tree for the moment
> and I put my patches into the asm-generic tree, then
> we can do the trivial cleanup from my final patch later.
>
I'll send a quick fix and reference there to your future cleanup queue.
Thanks,
Anna-Maria
On Mon, Feb 26, 2024, at 17:00, Anna-Maria Behnsen wrote:
> "Arnd Bergmann" <[email protected]> writes:
>> Commit a0d2fcd62ac2 ("vdso/ARM: Make union vdso_data_store
>> available for all architectures") introduced a reference to
>> the asm/page.h in include/vdso/datapage.h, but this is outside
>> of the vdso/*.h namespace and doesn't work in the compat vdso.
>
> But the asm namespace works for the vdso namespace. Only linux headers
> do not work, or am I wrong?
The vdso namespace was added to have something that works for
userspace code in both compat 32-bit mode and native (32 or
64) bit mode, while anything outside of include/vdso may not
work here.
> PAGE_SIZE is defined in asm/page-def.h for arm64. So this could be a
> fast fix (tested with clang-14):
>
> ---8<----
> --- a/include/vdso/datapage.h
> +++ b/include/vdso/datapage.h
> @@ -19,7 +19,11 @@
> #include <vdso/time32.h>
> #include <vdso/time64.h>
>
> +#ifdef CONFIG_ARM64
> +#include <asm/page-def.h>
> +#else
> #include <asm/page.h>
> +#endif
>
> #ifdef CONFIG_ARCH_HAS_VDSO_DATA
> #include <asm/vdso/data.h>
> ---8<---
I've sent my own patch now, which is something we probably want
anyway, but is obviously much more invasive thank your four-line
patch.
Maybe we can put your quick fix in the tip tree for the moment
and I put my patches into the asm-generic tree, then
we can do the trivial cleanup from my final patch later.
Arnd