Re: [PATCH] arm64/sve: fix genksyms generation

From: Will Deacon
Date: Tue Jun 18 2019 - 08:08:09 EST

Hi Arnd, Ard,

On Mon, Jun 17, 2019 at 05:45:56PM +0100, Will Deacon wrote:
> On Mon, Jun 17, 2019 at 06:32:16PM +0200, Ard Biesheuvel wrote:
> > The problem is not about the types we're *exporting*. Genksyms just
> > gives up halfway through the file, as soon as it encounters something
> > it doesn't like, and any symbol that hasn't been encountered yet at
> > that point will not have a crc generated for it.
> Hmm, but it appears to be either working or failing silently for me, which
> doesn't match what Arnd is seeing. I'd prefer to fix genksyms but I'm not
> happy touching it if I can't show it's broken to begin with. If I pass '-w'
> I see it barfing on all sorts of random stuff, for example the static_assert
> in include/linux/fs.h:
> static_assert(offsetof(struct filename, iname) % sizeof(long) == 0);

Ok, I had some more fun with this today. First of all, we needed a new
.config, but also, the issue only appears with linux-next. With that
configuration, I can hit the issue.

What seems to occur is that when parsing:

static __uint128_t arm64_cpu_to_le128(__uint128_t x)
u64 a = swab64(x);
u64 b = swab64(x >> 64);

return ((__uint128_t)a << 64) | b;

in fpsimd.c, then genksyms doesn't treate __uint128_t as a type and
therefore fails to figure out that this is a function. Consequently, it
keeps trying (and failing) to parse until it sees the end of the current
expression. This happens when it hits:


thanks to the semi-colon.

So one nasty bodge to fix this is:

diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index bb42cd04baec..693a978f41f9 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -368,6 +368,8 @@ static __uint128_t arm64_cpu_to_le128(__uint128_t x)

+short of_fixing_genksyms_we_must_use_this_hack;
#define arm64_le128_to_cpu(x) arm64_cpu_to_le128(x)


but actually, I think I've managed to hack genksyms itself. Patch below.