[5.16] missing <asm/fpu/xcr.h> include

[65a]

DKMS failure on torvalds/linux 5.15 branch. Not sure if missing new include or guarded now.

[65a]

Possibly related: torvalds/linux@b56d279

[65a]

It appears replacing includes of <asm/fpu/internal.h> with <asm/fpu/xcr.h> would fix this now missing transitive dependency previously included in internal.h

[jgottula]

As with #12757, it would have been helpful if you'd used the issue template. This is actually a Linux kernel 5.16 compat breakage, and the issue title should be changed to reflect that.

on torvalds/linux 5.15 branch

Linus doesn't do stable branches. After he tags v5.15 on his tree, everything that follows is for the v5.16 merge window and beyond. If you look at Greg KH's linux-stable tree, the <asm/fpu/internal.h> header is still quite existent in the linux-5.15.y branch.

Possibly related: torvalds/linux@b56d279

That does appear to be the exact commit at issue, yes. (Though it is just one of a 30-part patch set.)

Currently, ZFS header include/os/linux/kernel/linux/simd_x86.h conditionally includes <asm/fpu/api.h> and <asm/fpu/internal.h> depending on whether HAVE_KERNEL_FPU_API_HEADER is true.

It seems that there probably needs to be a new config check for the existence of <asm/fpu/internal.h> (separate from the existing check for e.g. <asm/fpu/api.h>) and a corresponding further conditionalization of the header include code in simd_x86.h to include <asm/fpu/xcr.h>—and any other FPU headers that might possibly also be necessary(?)—instead of <asm/fpu/internal.h>.

(Or, potentially, it could quite possibly be the case that including <asm/fpu/xcr.h>, rather than <asm/fpu/internal.h>, would actually have been sufficient for what was needed all along; in which case the header inclusion change could be made without a new configure check. I suppose this would require a fair amount of regression testing with older kernels to be completely confident in, however. But it's somewhat conceivable, since the simd_x86.h file really has not changed particularly much in the few years since becdcec.) Actually, never mind: upon closer inspection, that commit added alternatives to including <asm/fpu/{api,internal}.h>; so this is probably more bother than it'd be worth. Hate to make the FPU config labyrinth even uglier than it already is, though... 😜

[65a]

Able to reproduce with arch's 5.15 build (my own kernel config).

Something like

diff --git a/include/os/linux/kernel/linux/simd_x86.h b/include/os/linux/kernel/linux/simd_x86.h
index cdd3286d2..ce18468af 100644
--- a/include/os/linux/kernel/linux/simd_x86.h
+++ b/include/os/linux/kernel/linux/simd_x86.h
@@ -88,6 +88,7 @@
 #if defined(HAVE_KERNEL_FPU_API_HEADER)
 #include <asm/fpu/api.h>
 #include <asm/fpu/internal.h>
+#include <asm/fpu/xcr.h>
 #else
 #include <asm/i387.h>
 #include <asm/xcr.h>

works for me (and should also work on 5.16 as well).

[jgottula]

Able to reproduce with arch's 5.15 build (my own kernel config).

Interesting. The thought of unusual kernel configs did cross my mind early on, but I kinda just dismissed that idea once I realized there was a 5.16 component to the original issue report.

I know that the default Arch config for 5.15 works, and I know that my own customized config for 5.15 works. But it seems quite conceivable that there may be kernel config corner cases not fully anticipated in the OpenZFS code.

Could you upload your 5.15 config file that makes the build break?

Also, just for completeness, which particular 5.15.y stable version(s), or git commit(s) etc, have you seen this on? (Or does it appear to happen with basically any non-prerelease 5.15?)

[65a]

I am using the current Arch tag, https://github.com/archlinux/linux/tree/v5.15.4-arch1/arch/x86

Possibly scratch this, I will try the build again without this patch...I may have contaminated my patches that I apply during build with 5.16isms.

[satmandu]

Appears to be fixed by #12800 , though I'm still seeing
[5.16] blkcg_gq not found as an issue on build.

[behlendorf]

There are still some 5.16 compatibility issues we're working through. But as mentioned above this particularly Linux kernel API change has now been address by #12800. Older kernels might be effected if this recent upstream change ends up getting backported to those kernels. Closing.