From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A9A15C31E57 for ; Mon, 17 Jun 2019 11:26:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 86BE92084A for ; Mon, 17 Jun 2019 11:26:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728071AbfFQL05 (ORCPT ); Mon, 17 Jun 2019 07:26:57 -0400 Received: from foss.arm.com ([217.140.110.172]:46146 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727688AbfFQL04 (ORCPT ); Mon, 17 Jun 2019 07:26:56 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 86272344; Mon, 17 Jun 2019 04:26:56 -0700 (PDT) Received: from fuggles.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2CE733F246; Mon, 17 Jun 2019 04:28:40 -0700 (PDT) Date: Mon, 17 Jun 2019 12:26:52 +0100 From: Will Deacon To: Arnd Bergmann Cc: Catalin Marinas , Dave Martin , Ard Biesheuvel , Alex =?iso-8859-1?Q?Benn=E9e?= , Peter Maydell , Alan Hayward , Julien Grall , Marc Zyngier , Mark Rutland , Andrew Murray , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64/sve: fix genksyms generation Message-ID: <20190617112652.GB30800@fuggles.cambridge.arm.com> References: <20190617104237.2082388-1-arnd@arndb.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190617104237.2082388-1-arnd@arndb.de> User-Agent: Mutt/1.11.1+86 (6f28e57d73f2) () Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Arnd, On Mon, Jun 17, 2019 at 12:42:11PM +0200, Arnd Bergmann wrote: > genksyms does not understand __uint128_t, so we get a build failure > in the fpsimd module when it cannot export a symbol right: The fpsimd code is builtin, so which module is actually failing? My allmodconfig build succeeds, so I must be missing something. > WARNING: EXPORT symbol "kernel_neon_begin" [vmlinux] version generation failed, symbol will not be versioned. > /home/arnd/cross/x86_64/gcc-8.1.0-nolibc/aarch64-linux/bin/aarch64-linux-ld: arch/arm64/kernel/fpsimd.o: relocation R_AARCH64_ABS32 against `__crc_kernel_neon_begin' can not be used when making a shared object > arch/arm64/kernel/fpsimd.o:(.data+0x0): dangerous relocation: unsupported relocation > arch/arm64/kernel/fpsimd.o:(".discard.addressable"+0x0): dangerous relocation: unsupported relocation > arch/arm64/kernel/fpsimd.o:(".discard.addressable"+0x8): dangerous relocation: unsupported relocation > > We could teach genksyms about the type, but it's easier to just > work around it by defining that type locally in a way that genksyms > understands. > > Fixes: 41040cf7c5f0 ("arm64/sve: Fix missing SVE/FPSIMD endianness conversions") I can't see which part of that patch causes the problem, so I'm a bit wary of the fix. We've been using __uint128_t for a while now, and I see there's one in the x86 kvm code as well, so it would be nice to understand what's happening here so that we can avoid running into it in future as well. > Signed-off-by: Arnd Bergmann > --- > arch/arm64/kernel/fpsimd.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c > index 07f238ef47ae..2aba07cccf50 100644 > --- a/arch/arm64/kernel/fpsimd.c > +++ b/arch/arm64/kernel/fpsimd.c > @@ -400,6 +400,9 @@ static int __init sve_sysctl_init(void) { return 0; } > #define ZREG(sve_state, vq, n) ((char *)(sve_state) + \ > (SVE_SIG_ZREG_OFFSET(vq, n) - SVE_SIG_REGS_OFFSET)) > > +#ifdef __GENKSYMS__ > +typedef __u64 __uint128_t[2]; > +#endif I suspect I need to figure out what genksyms is doing, but I'm nervous about exposing this as an array type without understanding whether or not that has consequences for its operation. Will