modprobe zfs: Exec format error on ARMv7 (32-bit)

[awehrfritz]

System information

Type	Version/Name
Distribution Name	Armbian (Debian Buster)
Distribution Version	19.11.3
Linux Kernel	4.19.84-mvebu
Architecture	ARMv7 (32-bit)
ZFS Version	0.8.2
SPL Version	0.8.2

Describe the problem you're observing

When loading the zfs kernel model on a Helios4 NAS with a Marvell Armada 388 SoC (ARM Cortex-A9), modprob fails with the following error:
ERROR: could not insert 'zfs': Exec format error

The dmesg output seems to indicate that there is some CPU
instruction/function is missing:
zlua: section 4 reloc 44 sym 'longjmp': unsupported interworking call (Thumb -> ARM)

This is essentially a duplicate of issue #7408, which was however closed without addressing the underlying issue. As far as I can tell, the issue boils down to missing support for the Thumb-2 instruction set in module/lua/setjmp/setjmp_arm.S. The Thumb-2 instruction set is present, e.g., in ARM Cortex-A CPUs and the Armbian kernel for the Helios4 is all Thumb-2. @jsrlabs debugged this issue and found a workaround, and provided a patch to fix the issue.

Describe how to reproduce the problem

The issue can be reproduced by installing the zfs-dkms from the Debian buster-backports repository on a ARMv7 (32-bit) platform. Tested on a Helios4 NAS with a Marvell Armada 388 SoC (ARM Cortex-A9). This issue only occurs with ZFS version 0.8.2, version 0.7.12 works without problems on otherwise the exact same system.

[behlendorf]

Thanks for opening a new issue for this and referencing @jsrlabs proposed fix. I've created PR #9967 with a slightly updated of the patch for ARM and Thumb-2 so we can get it reviewed and merged.

Unfortunately, I don't have access to the required hardware to test the fix so if you're able to do so that would be exceptionally helpful. Internally ZFS uses this code for the zfs destroy command. So a relatively easy way to test it would to create a new throw away dataset, a few snapshots, and then destroy them.

[awehrfritz]

Wow, that was quick! Thanks @behlendorf for addressing this issue right away. I will look into testing this on my system.

[jsrlabs]

I'll also try this sometime this weekend. Thanks for the fix!