public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Catalin Marinas" <catalin.marinas@arm.com>,
	"Dave Martin" <Dave.Martin@arm.com>,
	"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Alan Hayward" <alan.hayward@arm.com>,
	"Julien Grall" <julien.grall@arm.com>,
	"Marc Zyngier" <marc.zyngier@arm.com>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Andrew Murray" <andrew.murray@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64/sve: fix genksyms generation
Date: Mon, 17 Jun 2019 12:26:52 +0100	[thread overview]
Message-ID: <20190617112652.GB30800@fuggles.cambridge.arm.com> (raw)
In-Reply-To: <20190617104237.2082388-1-arnd@arndb.de>

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 <arnd@arndb.de>
> ---
>  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

  reply	other threads:[~2019-06-17 11:26 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-17 10:42 [PATCH] arm64/sve: fix genksyms generation Arnd Bergmann
2019-06-17 11:26 ` Will Deacon [this message]
2019-06-17 12:21   ` Arnd Bergmann
2019-06-17 14:59     ` Alex Bennée
2019-06-17 15:10       ` Arnd Bergmann
2019-06-17 16:13     ` Will Deacon
2019-06-17 16:32       ` Ard Biesheuvel
2019-06-17 16:45         ` Will Deacon
2019-06-18 12:02           ` Will Deacon
2019-06-18 14:15             ` Arnd Bergmann
2019-07-09 19:06               ` Laura Abbott
2019-07-10  8:15                 ` Will Deacon
2019-07-10  8:48                   ` Masahiro Yamada

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190617112652.GB30800@fuggles.cambridge.arm.com \
    --to=will.deacon@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=alan.hayward@arm.com \
    --cc=alex.bennee@linaro.org \
    --cc=andrew.murray@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=julien.grall@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=peter.maydell@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox