Linux kernel 5.x removing FPU and SIMD instructions

[fryfrog]

This could be a big headache for the 5.0+ kernel and ZFS. It is probably mostly going to be OpenZFS/ZoL dealing with it, but archzfs may have to do something as well? Like stick w/ the last 4.x kernel or something. :(

https://old.reddit.com/r/linux/comments/aexfh3/greg_kroahhartman_my_tolerance_for_zfs_is_pretty/

[minextu]

Yeah that's unfortunate. If no stable patches are available by the time 5.0 hits arch, I'll have to disable building this kernel. So you would either have to stop upgrading the kernel and stick with 4.x or use linux-lts

[netvl]

Looks like workarounds in ZoL are merged: openzfs/zfs#8287

[fryfrog]

And now 5.0 is out of testing and into core.

Edit: And it looks like there was a release yesterday to support it, https://github.com/zfsonlinux/zfs/releases/tag/zfs-0.7.13. Thanks to /u/FTWGeorge on Reddit for pointing it out.

[minextu]

Packages have been updated for 5.0, but zfs-rc has been disabled for now, until a new release is published.

[rajil]

Can this patch be brought in, https://www.phoronix.com/scan.php?page=news_item&px=NixOS-Linux-5.0-ZFS-FPU-Drop?

[minextu]

Unfortunately the Linux kernel itself needs to be patched. So there is no way to put it in archzfs (except maybe creating a custom kernel just for that)

[fryfrog]

That's what I was thinking. I've snagged the linux PKGBUILD and am having a go at doing that now.

[rajil]

@fryfrog do update this thread when you have something working.

[fryfrog]

It totally works and is super easy. I installed asp, then asp update and asp checkout linux, go to the trunk folder and use git log to find the hash of the kernel you're running (one of my systems is stuck on 5.0.13, the other is building 5.1.4 right now). Edit the PKGBUILD to add https://raw.githubusercontent.com/NixOS/nixpkgs/master/pkgs/os-specific/linux/kernel/export_kernel_fpu_functions.patch in sources, update the pkg sums and generate the .SRCINFO file (updpkgsums && mksrcinfo on my system, but I think they're aliases). Then just makepkg -s. The PKGBUILD is pre-made to apply any .patch file mentioned in sources. Neat.

I also took this opportunity to switch to zfs-dkms.

[fryfrog]

Because I have no idea why my server boots my kernel, I needed to use the linux package. I'm not sure if I should push a linux-fpu or linux-simd to the AUR, it seems a little crazy just for this.

I wonder if Arch Linux kernel maintainer's would include it?

[rajil]

@fryfrog i had to install pacman-contrib to get updpkgsums, but cant find the package for mksrcinfo.

How about makepkg --printsrcinfo >.SRCINFO

[fryfrog]

Yup, that is exactly it. I think mksrcinfo used to be a real command, but was replaced by makepkg --printsrcinfo > .SRCINFO. Instead of re-learning it, I just aliased it.

[WoefulDerelict]

mksrcinfo and a handful of other legacy utilities are provided by pkgbuild-introspection for which a PKGBUILD exists in the AUR. As the tooling is no longer relevant it was dropped from the Arch Linux repos. Systems that have been rolling for a while may have the tool lurking.

It is not necessary to generate a .SRCINFO file to build the package, only when uploading to the AUR.

[fryfrog]

15:28 < fryfrog> heftig: are you familiar w/ the stripping of the fpu/simd stuff that zfs depended on?
15:28 < heftig> not getting readded, sorry

[solenskiner]

please vote on https://bugs.archlinux.org/task/63082

[Ingramz]

The issue was closed quite quickly. I created an account just so I could vote and also attempted to get this issue open again with the explanation:

Newsitem related to the NixOS patch: https://www.phoronix.com/scan.php?page=news_item&px=NixOS-Linux-5.0-ZFS-FPU-Drop

Upstream is not intersted in maintaining this piece of code due to ZFS having the "wrong" license. This is a political problem and not really a technical one.

OpenZFS community considered finding a compromise that would suit the Kernel developers, but since the interest was only one-sided, this idea was put to a halt. (openzfs/zfs#8314)

The patch is fairly simple and definitely of great help to any pragmatic ZFS users on Arch out there. Including it in the main kernel would spare ArchZFS repository from shipping their own kernel/having to build their own kernel compilation infrastructure.

This request was denied by @eli-schwartz with the following response:

You seem to have mistaken Arch Linux for a distribution that has an interest in applying politically motivated downstream patches that upstream has explicitly rejected.

I replied with

...
No, I'm sorry if it came out like that. The patch itself is a revert of piece of code that existed in upstream, so it's not really a downstream patch that was rejected from getting to upstream. The patch reverts functionality that upstream abandoned. Pre-kernel 5.0 this code existing in upstream was completely fine, no distribution explicitly patching this out. So why reject it now?

I'm not going to comment on the political details of this issue, I was merely hinting that upstream has issues with ZFS and its licensing in case you were not aware. ZFS users are trying to regain the performance lost by an upstream decision that was considered a maintenance burden. If Arch Linux by extension of kernel upstream developers does not support its ZFS subcommunity for the same reasons (please tell if this the case), then I'll refrain from any further discussion.

Anyway this was simply dismissed without explanation.

I tried, sorry if I ruined someone else's chances. Let this serve as additional evidence that they are not interested.

[eli-schwartz]

You have not ruined anyone else's chance. There was never a chance. Don't bother voting on the bug.

[mati865]

To defend the maintainers, from Arch wiki:

Arch Linux defines simplicity as without unnecessary additions or modifications. It ships software as released by the original developers (upstream) with minimal distribution-specific (downstream) changes: patches not accepted by upstream are avoided, and Arch's downstream patches consist almost entirely of backported bug fixes that are obsoleted by the project's next release.

By choosing Arch you are accepting it's principles.

[Ingramz]

@eli-schwartz thank you for the detailed explanation you added to the bug. Closing it down with vague a one-liner hiding behind upstream, without any additional context is pretty much asking for it to be reopened.

This issue caused a lot more controversy within the communities than anything else in recent time, which is why I think it also deserves the mentioned rare consideration and dialogue.

What you wrote makes perfect sense, if I wasn't affected by this, I'd say "no" as well. It is just a burden if you cannot appreciate its value. Whether the code is illegal or actually violates someones copyright, not 100% sure, for now it seems about as weak argument as any technical one. I don't think anyone leading to this issue is at fault here, regardless of whether it was the OpenZFS' decision to depend on the kernel functionality or upstream's decision to abandon the code, everyone had their reasons.

In conclusion, we can better understand your stance on the issue now compared to the information we had 3 hours ago. We will know to look elsewhere. Thank you for participating.

@mati865 this can be easily countered with the sections "Pragmatism" and "User centrality". If there was a consensus that this patch is incredibly useful despite the maintenance burden/political issues, the ideological barrier could be looked past.

[eli-schwartz]

Whether the code is illegal or actually violates someones copyright, not 100% sure, for now it seems about as weak argument as any technical one.

It's the argument being made by at least some kernel maintainers. I don't know enough about it to pass judgment.

If there was a consensus that this patch is incredibly useful

(which it isn't because it only helps an AUR kernel module)

despite the maintenance burden

Which is not huge, so it just requires someone who wants to invest the time, not someone with expert domain knowledge, but we don't have either one.

political issues

... in the case of licensing, are so not-fun that Arch with its lack of paid lawyers simply won't touch it with a ten-foot pole, in my experience.

[Ingramz]

... in the case of licensing, are so not-fun that Arch with its lack of paid lawyers simply won't touch it with a ten-foot pole, in my experience.

That's understandable and this seems to align with the reason why ZFS in its current form will probably never make it outside AUR, despite it's relative popularity.

[WoefulDerelict]

With any luck this point will soon be moot; however, there may still be an additional maintenance burden for users wishing to use ZFS on Arch Linux systems.

The licencing conflicts between Linux and ZFS remain ongoing and grow increasingly unlikely to change as the codebases continue to mature.

[WoefulDerelict]

If for some reason you are unaware this is a summary of the incompatibility between the CDDL and the GPL from the perspective shared by most of the Linux kernel developers. An even more detailed dissection can be found here.

The CDDL's self defense clause runs afoul of the GPL's aggressive copyleft clause and the file based separation between source and binary along with ZFS's presence as a module is not enough to satisfy the Linux kernel's core directors.

[rajil]

The patch no longer exists at the source. Anybody has the new location?

[fryfrog]

They have patches now for a few major kernel versions, look near by. I'll link later when I'm not on mobile.

[fryfrog]

In case you didn't find them, they're here: https://github.com/NixOS/nixpkgs/tree/master/pkgs/os-specific/linux/kernel

[rajil]

The patch for 5.3 kernel is this.

[rajil]

Do we need to remove this patch with zfs 0.8.3, since it is already patched?

[fryfrog]

They were never applied.

[rajil]

I applied the patch mentioned in the above post to my kernel. Do I need to undo the patch before upgrading to zfs 0.8.3?

[fryfrog]

Oh, it doesn't matter. FWIW, I'm still patching my kernels. Just don't patch the next kernel.