Linus master branch failed to build the arm64 architecture due to below error and warnings.
kernel config: https://builds.tuxbuild.com/Dp3s1p4uYnGpImQwCvhzEw/kernel.config
git_repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git target_arch: arm64 toolchain: gcc-9 git_short_log: 83bdc7275e62 (\random32: remove net_rand_state from the latent entropy gcc plugin) git_describe: v5.8-rc7-40-g83bdc7275e62
make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j16 ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- HOSTCC=gcc CC="sccache aarch64-linux-gnu-gcc" O=build Image # In file included from ../arch/arm64/include/asm/smp.h:33, from ../include/linux/smp.h:82, from ../include/linux/percpu.h:7, from ../include/linux/random.h:14, from ../arch/arm64/kernel/pointer_auth.c:5: ../arch/arm64/include/asm/pointer_auth.h: In function ‘ptrauth_keys_init_user’: ../arch/arm64/include/asm/pointer_auth.h:40:3: error: implicit declaration of function ‘get_random_bytes’; did you mean ‘get_random_once’? [-Werror=implicit-function-declaration] 40 | get_random_bytes(&keys->apia, sizeof(keys->apia)); | ^~~~~~~~~~~~~~~~ | get_random_once In file included from ../arch/arm64/kernel/pointer_auth.c:5: ../include/linux/random.h: At top level: ../include/linux/random.h:41:13: warning: conflicting types for ‘get_random_bytes’ 41 | extern void get_random_bytes(void *buf, int nbytes); | ^~~~~~~~~~~~~~~~ In file included from ../arch/arm64/include/asm/smp.h:33, from ../include/linux/smp.h:82, from ../include/linux/percpu.h:7, from ../include/linux/random.h:14, from ../arch/arm64/kernel/pointer_auth.c:5: ../arch/arm64/include/asm/pointer_auth.h:40:3: note: previous implicit declaration of ‘get_random_bytes’ was here 40 | get_random_bytes(&keys->apia, sizeof(keys->apia)); | ^~~~~~~~~~~~~~~~ cc1: some warnings being treated as errors
build log link, https://gitlab.com/Linaro/lkft/kernel-runs/-/jobs/662908458
Hi Naresh,
On Thu, 30 Jul 2020 16:25:49 +0530 Naresh Kamboju naresh.kamboju@linaro.org wrote:
Linus master branch failed to build the arm64 architecture due to below error and warnings.
Thanks for the report.
Please see https://lore.kernel.org/lkml/202007292007.D87DBD34B@keescook/
On 30/07/2020 14:15, Stephen Rothwell wrote:
Hi Naresh,
On Thu, 30 Jul 2020 16:25:49 +0530 Naresh Kamboju naresh.kamboju@linaro.org wrote:
Linus master branch failed to build the arm64 architecture due to below error and warnings.
Thanks for the report.
Please see https://lore.kernel.org/lkml/202007292007.D87DBD34B@keescook/
I'd like to note that below set of patches: 1c9df907da83 random: fix circular include dependency on arm64 after addition of percpu.h 83bdc7275e62 random32: remove net_rand_state from the latent entropy gcc plugin f227e3ec3b5c random32: update the net random state on interrupt and activity
also break ARM build for the case: #if defined(CONFIG_SMP) && !defined(CONFIG_CPU_V6)
config: keystone_defconfig
CC arch/arm/kernel/signal.o In file included from ../include/linux/random.h:14, from ../arch/arm/kernel/signal.c:8: ../arch/arm/include/asm/percpu.h: In function ‘__my_cpu_offset’: ../arch/arm/include/asm/percpu.h:29:34: error: ‘current_stack_pointer’ undeclared (first use in this function); did you mean ‘user_stack_pointer’? : "Q" (*(const unsigned long *)current_stack_pointer)); ^~~~~~~~~~~~~~~~~~~~~ user_stack_pointer ../arch/arm/include/asm/percpu.h:29:34: note: each undeclared identifier is reported only once for each function it appears in ../scripts/Makefile.build:280: recipe for target 'arch/arm/kernel/signal.o' failed make[2]: *** [arch/arm/kernel/signal.o] Error 1 /home/grygorii/kernel.org/linux-master/linux/Makefile:1756: recipe for target 'arch/arm/kernel' failed make[1]: *** [arch/arm/kernel] Error 2
On Thu, Jul 30, 2020 at 11:47 AM Grygorii Strashko grygorii.strashko@ti.com wrote:
I'd like to note that below set of patches: 1c9df907da83 random: fix circular include dependency on arm64 after addition of percpu.h 83bdc7275e62 random32: remove net_rand_state from the latent entropy gcc plugin f227e3ec3b5c random32: update the net random state on interrupt and activity
also break ARM build for the case: #if defined(CONFIG_SMP) && !defined(CONFIG_CPU_V6)
Lovely.
I think I'll have to revert 1c9df907da83 after all, and use Marc Zyngier's patch to just remove that troublesome <asm/pointer_auth.h> include in arm64 instead.
This turned out to be much messier than it should have been.
Linus
On 30/07/2020 21:56, Linus Torvalds wrote:
On Thu, Jul 30, 2020 at 11:47 AM Grygorii Strashko grygorii.strashko@ti.com wrote:
I'd like to note that below set of patches: 1c9df907da83 random: fix circular include dependency on arm64 after addition of percpu.h 83bdc7275e62 random32: remove net_rand_state from the latent entropy gcc plugin f227e3ec3b5c random32: update the net random state on interrupt and activity
also break ARM build for the case: #if defined(CONFIG_SMP) && !defined(CONFIG_CPU_V6)
Lovely.
I think I'll have to revert 1c9df907da83 after all, and use Marc Zyngier's patch to just remove that troublesome <asm/pointer_auth.h> include in arm64 instead.
This turned out to be much messier than it should have been.
FYI. Below diff seems fixes build:
diff --git a/arch/arm/include/asm/percpu.h b/arch/arm/include/asm/percpu.h index f44f448537f2..1a3eedbac4a2 100644 --- a/arch/arm/include/asm/percpu.h +++ b/arch/arm/include/asm/percpu.h @@ -5,6 +5,8 @@ #ifndef _ASM_ARM_PERCPU_H_ #define _ASM_ARM_PERCPU_H_
+#include <asm/thread_info.h> + /* * Same as asm-generic/percpu.h, except that we store the per cpu offset * in the TPIDRPRW. TPIDRPRW only exists on V6K and V7
On Thu, Jul 30, 2020 at 12:05 PM Grygorii Strashko grygorii.strashko@ti.com wrote:
FYI. Below diff seems fixes build:
Thanks, I'll do that instead, it looks like the right thing to do regardless.
Mind sending me a sign-off for it (and commit message would be lovely too, but I can make something up)? Yeah, it's just a one-liner, but let's do this right.
Thanks, Linus
On 30/07/2020 22:40, Linus Torvalds wrote:
On Thu, Jul 30, 2020 at 12:05 PM Grygorii Strashko grygorii.strashko@ti.com wrote:
FYI. Below diff seems fixes build:
Thanks, I'll do that instead, it looks like the right thing to do regardless.
Mind sending me a sign-off for it (and commit message would be lovely too, but I can make something up)? Yeah, it's just a one-liner, but let's do this right.
I've also boot-tested it on Keystone 2 platforms.
Best regards, grygorii
--- From fa1238a8e4b7c603fcc0fb5f6169c212035aef4f Mon Sep 17 00:00:00 2001 From: Grygorii Strashko grygorii.strashko@ti.com Date: Thu, 30 Jul 2020 22:05:01 +0300 Subject: [PATCH] ARM: percpu.h: fix build error MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit
Fix build error for the case: defined(CONFIG_SMP) && !defined(CONFIG_CPU_V6)
config: keystone_defconfig
CC arch/arm/kernel/signal.o In file included from ../include/linux/random.h:14, from ../arch/arm/kernel/signal.c:8: ../arch/arm/include/asm/percpu.h: In function ‘__my_cpu_offset’: ../arch/arm/include/asm/percpu.h:29:34: error: ‘current_stack_pointer’ undeclared (first use in this function); did you mean ‘user_stack_pointer’? : "Q" (*(const unsigned long *)current_stack_pointer)); ^~~~~~~~~~~~~~~~~~~~~ user_stack_pointer
Fixes: f227e3ec3b5c ("random32: update the net random state on interrupt and activity") Signed-off-by: Grygorii Strashko grygorii.strashko@ti.com --- arch/arm/include/asm/percpu.h | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/arch/arm/include/asm/percpu.h b/arch/arm/include/asm/percpu.h index f44f448537f2..1a3eedbac4a2 100644 --- a/arch/arm/include/asm/percpu.h +++ b/arch/arm/include/asm/percpu.h @@ -5,6 +5,8 @@ #ifndef _ASM_ARM_PERCPU_H_ #define _ASM_ARM_PERCPU_H_
+#include <asm/thread_info.h> + /* * Same as asm-generic/percpu.h, except that we store the per cpu offset * in the TPIDRPRW. TPIDRPRW only exists on V6K and V7
On Thu, Jul 30, 2020 at 12:40:01PM -0700, Linus Torvalds wrote:
On Thu, Jul 30, 2020 at 12:05 PM Grygorii Strashko grygorii.strashko@ti.com wrote:
FYI. Below diff seems fixes build:
Thanks, I'll do that instead, it looks like the right thing to do regardless.
Mind sending me a sign-off for it (and commit message would be lovely too, but I can make something up)? Yeah, it's just a one-liner, but let's do this right.
Don't you want to take Mark's patch anyway in addition to all this ? In case anyone meets yet another build issue, they'd have more luck trying to revert any other patch. Right now if they revert one, it breaks the build in a different way and doesn't help much.
Willy
On Thu, Jul 30, 2020 at 7:16 PM Willy Tarreau w@1wt.eu wrote:
Don't you want to take Mark's patch anyway in addition to all this ? In case anyone meets yet another build issue, they'd have more luck trying to revert any other patch. Right now if they revert one, it breaks the build in a different way and doesn't help much.
I think Will picked up Mark's patch into the arm64 tree, so I felt I should let it come in eventually that way.
The immediate problems seem to have been resolved.
Knock wood.
Linus
On Thu, Jul 30, 2020 at 10:25:41PM -0700, Linus Torvalds wrote:
On Thu, Jul 30, 2020 at 7:16 PM Willy Tarreau w@1wt.eu wrote:
Don't you want to take Mark's patch anyway in addition to all this ? In case anyone meets yet another build issue, they'd have more luck trying to revert any other patch. Right now if they revert one, it breaks the build in a different way and doesn't help much.
I think Will picked up Mark's patch into the arm64 tree, so I felt I should let it come in eventually that way.
OK then!
The immediate problems seem to have been resolved.
Knock wood.
Yes, that's my feeling as well. I'm going to resend you your patch moving prandom32 definitions to prandom.h rebased on these latest changes, add add a commit message. It would be nice for 5.9, but maybe it could put an end to this mess once for all :-/
Willy
On Thu, Jul 30, 2020 at 10:25:41PM -0700, Linus Torvalds wrote:
On Thu, Jul 30, 2020 at 7:16 PM Willy Tarreau w@1wt.eu wrote:
Don't you want to take Mark's patch anyway in addition to all this ? In case anyone meets yet another build issue, they'd have more luck trying to revert any other patch. Right now if they revert one, it breaks the build in a different way and doesn't help much.
I think Will picked up Mark's patch into the arm64 tree, so I felt I should let it come in eventually that way.
Yup, you'll get it later today with a few other fixes that have trickled in.
Cheers,
Will