build fails on aarch64 with kernel 6.17+

[q66]

System information

Type	Version/Name
Distribution Name	Chimera Linux
Distribution Version	rolling
Kernel Version	6.17.x
Architecture	aarch64
OpenZFS Version	2.3.4 with backports (affects any version)

The following commit: torvalds/linux@9a6d3ff introduced an __aarch64__ check to the BITS_PER_LONG macro to avoid UB when compiling the 32-bit compat vDSO.

This breaks ZFS build because the zstd module inexplicably undefs __aarch64__ in the aarch64_compat.h header (module/zstd/include/aarch64_compat.h), without specifying any reason why. This causes __BITS_PER_LONG to become 32, which breaks due to __kernel_size_t becoming 4, which makes FORTIFY diagnostic checks in string.h error.

[n0xena]

2.3.4 is 6.16 only!
for 6.17 you have to use 2.4-rc

[q66]

that's irrelevant to the issue (i have backports for 6.17 compat and also the issue exists on every version of zfs)

[robn]

So while it does bump into the FORTIFY checks, it seems to compile clean otherwise.

Seems it was introduced in #10278 to workaround a toolchain issue. It's popped up a couple of times since, notably in #14714 (comment). I'm not sure, but it seems to be a bruteforce way to disable generation/use of NEON instructions in the kernel, where we don't currently have a way to properly manage the registers?

@mcmilk you might have the most up-to-date knowledge of what this is, can you enlighten me? I'm happy to spend the time working out a tighter workaround if its still necessary; I just need to know what I'm aiming at. Thanks!

[q66]

it does not "compile clean", at least not with clang (__diagnose_as_builtin errors) and even if it did having kernel typedefs become incorrect size is just asking for real trouble

[robn]

Well, it did for me without FORTIFY enabled, thus "otherwise". And yes, I'm well aware of the danger, which is why I asked someone for more information, because before I do anything I want to understand why it's like this.

[q66]

oh, i may have misunderstood your post, apologies

yeah it'll probably compile fine without fortify, but with potential consequences

[mcmilk]

Hello,

@robn - I am sorry for my late reply on this. Unfortunately, I don’t have time to investigate this issue at the moment - perhaps in December.

@q66 - at present, the OpenZFS team lacks a robust setup for automated testing on ARM-based systems. I’m addressing this, but it’s not at the top of my priority list.

[behlendorf]

it seems to be a brute-force way to disable generation/use of NEON instructions in the kernel

That's my read of it as well. In the kernel we need to save/restore the FPU registers around any SIMD instructions. That isn't done here so these optimizations do need to be disabled. Setting ZSTD_NO_INTRINSICS for the kernel build looks like a far better way to handle this. I've opened #17904 with this change.

Unfortunately, I don't have an aarch64 system handy to test this out. @q66 @robn, or @mcmilk any chance on of you could test this out.