Compile failure with Linux 5.5-rc2 and CONFIG_PREEMPT_RCU=y #9745

artee666 · 2019-12-18T21:02:34Z

Describe the problem you're observing

Cannot compile zfs for 5.5-rc2. There's the following error:
FATAL: modpost: GPL-incompatible module zfs.ko uses GPL-only symbol '__rcu_read_lock'

PrivatePuffin · 2019-12-18T23:21:12Z

Please be aware 5.5(rc2) isn't a supported kernel at the moment.
It might be worthwhile making an feature request issue for 5.5 kernel support instead.

behlendorf · 2019-12-19T00:13:16Z

If I were to hazard a guess, I'd say that your kernel is built with CONFIG_PREEMPT_RCU which is incompatible with ZFS. Can you check your kernel configuration to see if that is the case? This is something we've been meaning to add a check for so it's detected at configure time.

artee666 · 2019-12-19T05:27:06Z

@behlendorf yes, the kernel is built with CONFIG_PREEMPT_RCU, but my current kernel 5.4.4 is built with this option as well and ZFS is working with it

wolfgangwuerfl · 2019-12-21T09:04:06Z

@behlendorf i got the same issue, CONFIG_PREEMPT_RCU depends on CONFIG_PREEMPT, does that mean its not possible to build a full preemptive kernel since 5.5 with zfs? I switched to voluntary preemption and the module builds without GPL incompatibility (again).

Is there a plan to move the printk stuff to the SPL as a stub? It guess the error comes from the real time preparation for the kernel log infrastructure.

XHDR · 2020-01-10T20:27:49Z

I'm not sure if something has changed, kernel wise, in between rc2 and rc5, but ZFS build fine on a locally patched kernel. I'm exporting __rcu_read_{lock,unlock}, just like kernel_fpu_{begin,end}.
Currently running kernel version 5.5-rc5, and ZFS 0.8.0.r512.gba0ba69e5 on Arch Linux.

$ zgrep CONFIG_PREEMPT_RCU /proc/config.gz
CONFIG_PREEMPT_RCU=y

$ zfs list
NAME   USED  AVAIL     REFER  MOUNTPOINT
zfoo  1.00G   768M     1.00G  /zfoo

PrivatePuffin · 2020-01-10T20:38:45Z

@XHDR So basically: Cant reproduce?

XHDR · 2020-01-10T21:07:50Z

@XHDR So basically: Cant reproduce?

I'm not sure if that's the correct term for it, as I am running a patched version of 5.5-rc5, but:
Yes, basically.

When I've got more time on my hands, I'll try a clean, non-patched version, and see if it happens there. But for now, just experimenting with ZFS for the first time, my experience is that it seems to compile and run as it should.

Edit:
Reverting the EXPORT_SYMBOL changes to __rcu_read_{lock,unlock} results in the same error as OP:

FATAL: modpost: GPL-incompatible module zfs.ko uses GPL-only symbol '__rcu_read_lock'

The commit in question:

diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index fa08d55f7040c0aa6a9976b328cb8c49195824d6..360428642c9bd34670683eb587110baf2ef24bd2 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -360,7 +360,7 @@ void __rcu_read_lock(void)
 		WARN_ON_ONCE(current->rcu_read_lock_nesting > RCU_NEST_PMAX);
 	barrier();  /* critical section after entry code. */
 }
-EXPORT_SYMBOL_GPL(__rcu_read_lock);
+EXPORT_SYMBOL(__rcu_read_lock);
 
 /*
  * Preemptible RCU implementation for rcu_read_unlock().
@@ -390,7 +390,7 @@ void __rcu_read_unlock(void)
 		WARN_ON_ONCE(rrln < 0 && rrln > RCU_NEST_NMAX);
 	}
 }
-EXPORT_SYMBOL_GPL(__rcu_read_unlock);
+EXPORT_SYMBOL(__rcu_read_unlock);
 
 /*
  * Advance a ->blkd_tasks-list pointer to the next entry, instead

PrivatePuffin · 2020-01-11T11:01:02Z

Ahh, yes it seems they did the good old "Lets put something GPL-only to screw with non-gpl kernel modules just for lolz". Again.

Should be relatively easy to add this to the condom.

freswa · 2020-01-22T20:15:54Z

@behlendorf Any chance we can get a patch into 0.8.3 and out until 5.5 becomes stable and the first user run into problems?

behlendorf · 2020-01-22T22:12:32Z

What needs to be done is to identify which function we're calling now incidentally calls __rcu_read_lock. One way to narrow down the possible functions would be to verify that unsetting CONFIG_PREEMPT_RCU prevents the build failure. Then we'll be able to determine what can be done. If would be helpful if someone could perform this test and post the results.

tycho · 2020-01-23T05:10:00Z

The object referencing __rcu_read_unlock is ./module/os/linux/zfs/vdev_disk.o. The reference chain is basically: __rcu_read_unlock -> rcu_read_unlock -> percpu_ref_tryget -> blkg_tryget -> vdev_bio_associate_blkg.

rkitover · 2020-01-24T12:23:03Z

I can confirm this issue on the latest linus tree master.

I tried commenting out just CONFIG_PREEMPT_RCU=y in .config, but make oldconfig always puts it back. make menuconfig shows that this option cannot be set directly.

If you guys like, I can write a config/kernel-rcu-is-gpl.m4 or some such to test whether __rcu_read_lock is a GPL symbol or not, if that would help.

artee666 · 2020-01-24T13:12:13Z

You need to set General setup -> Preemption Model to different setting than Preemptible Kernel (Low-Latency Desktop). For example to Voluntary Kernel Preemption (Desktop). Then zfs will compile just fine.

behlendorf · 2020-01-24T17:44:48Z

@tycho thanks for the call chain, that makes sense.

Lalufu · 2020-01-31T10:17:41Z

Reading this, if I have a non-preempt kernel (CONFIG_PREEMPT is not set), like Fedora ships by default, 5.5 should just work with zfs 0.8.3?

ndowens · 2020-02-03T13:10:13Z

Also wanted to add, I got this issue with:5.5.1

rkitover · 2020-02-03T23:59:18Z

For what it's worth, this incompatibility should not affect too many people as most distro kernels do not use preempt, as far as I know, and when they do it is through optional kernel packages like arch does.

tycho · 2020-02-04T00:04:34Z

@rkitover The stock Arch kernel has CONFIG_PREEMPT and CONFIG_PREEMPT_RCU:

https://git.archlinux.org/svntogit/packages.git/tree/linux/trunk/config#n98
https://git.archlinux.org/svntogit/packages.git/tree/linux/trunk/config#n124

CONFIG_PREEMPT_VOLUNTARY is much more popular with distributions though (Fedora, SuSE, Ubuntu all use it).

wavexx · 2020-02-04T08:32:27Z

On Tue, Feb 04 2020, Steven Noonan wrote: @rkitover The stock Arch kernel has CONFIG_PREEMPT and CONFIG_PREEMPT_RCU: https://git.archlinux.org/svntogit/packages.git/tree/linux/trunk/config#n98 https://git.archlinux.org/svntogit/packages.git/tree/linux/trunk/config#n124

I'm doing the same via the linux-image-rt kernels on debian. I've been doing that for years. This issue though started popping up with the 5.4 series, where even the stock image has preempt-rcu enabled.

YaroKasear · 2020-02-04T15:59:21Z

Is there anything an end-user can do to workaround this problem? Downgrade the kernel? I'm using Arch Linux and this GPL-only nonsense is going to keep me from rebooting as this literally means I can't boot with the new kernel, rendering my system unusable.

ndowens · 2020-02-04T16:03:26Z

I have been using the lts kernel fine

…

On Tue, Feb 4, 2020 at 9:59 AM YaroKasear ***@***.***> wrote: Is there anything an end-user can do to workaround this problem? Downgrade the kernel? I'm using Arch Linux and this GPL-only nonsense is going to keep me from rebooting as this literally means I can't boot with the new kernel, rendering my system unusable. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9745>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA4X36SG2G23NEHXE4UJQDRBGGFVANCNFSM4J4RWSVQ> .

WoefulDerelict · 2020-02-05T05:43:31Z

@YaroKasear End users on Arch Linux have two options. Your first and by far the easiest option is to downgrade or use the LTS kernel. The second option is to revert the offending change in the 5.5 series via a patch and build/manage the kernel yourself. There is plenty of tooling to help you out but if you've never used the Arch Build System before this would prove quite the adventure. While some users have reported success building and running ZoL 0.8.3 against patched versions of Linux 5.5 this isn't presently supported and you may encounter other issues.

dagaz · 2020-02-05T08:54:12Z

Is there anything an end-user can do to workaround this problem? Downgrade the kernel? I'm using Arch Linux and this GPL-only nonsense is going to keep me from rebooting as this literally means I can't boot with the new kernel, rendering my system unusable.

I think the obvious option is: Downgrade the kernel.
You can update your system, leaving out the kernel:

pacman -Suy --ignore=linux,linux-headers

I did it that way all previous problematic kernels until the zfs developers found a soloution.

francoism90 · 2020-02-06T09:59:29Z

Just to add one can use the Arch Linux Archive to downgrade to Linux 5.4.8, other (major) distro's should supply an archive as well.

Hope you guys can find a solution and I understand testing it with the latest kernel(s) takes time. :)

artee666 · 2020-02-06T11:19:51Z

In archlinux the linux-lts package will soon be based on 5.4.x (5.4.18 is currently in testing). And also linux-lts does not have RCU compiled in (as it is based on No Forced Preemption (Server) preemption model).

francoism90 · 2020-02-08T08:10:46Z

Offtopic:
@artee666 I've tried compiling zfs-linux-lts against linux-lts from testing, this however results in Unable to build an empty module. Do you use this package as well? :)

jonathonf · 2020-02-12T17:53:04Z

I've put together a very hacky patch which will prevent the need to reconfigure/recompile your kernel:

https://gitlab.manjaro.org/packages/extra/linux55-extramodules/spl_zfs/blob/rcu-patch/linux-5.5-rcu.patch

Essentially this overrides/reverts percpu_ref_tryget from torvalds/linux@9e8d42a within https://github.com/zfsonlinux/zfs/blob/zfs-0.8.3/module/zfs/vdev_disk.c

It's very hacky and not tested very much beyond the fact that zfs.ko will compile and I can access a couple of pools (edit, and it seems fine after a day's general use).

Did I mention that it's very much a hack? OK.

dreamcat4 · 2020-02-13T19:01:10Z

So your patch seems to be different from these other 2 compatibility patches. Which seem to be for the newer 5.6.x release candidate kernel instead of current 5.5.x

#9961

[edited] oh this 2nd ubuntu pastebin patched is based of the same PR 9961

#9961 (comment)

My question then would be (this about other PR) if then still requires the recompilation of certain kernels setting as discussed here (such as for the ubuntu kernel). Since that is not mentioned in them it isn't clear to me whether we also need this still patched in for 5.6 too.... or can wait to skip over the 5.5 kernel series entirely to get 0.8.3 working back again. My gut feeling is no these are separate issues and this issue still needs to be fixed for kernels 5.6 too (anything 5.5 or higher).

Agree / disagree?

jonathonf · 2020-02-13T19:04:52Z

The 5.6 compat patches don't address the change in 5.5 behaviour, they fix other compat issues.

The above commit torvalds/linux@9e8d42a is tagged for 5.6-rc1 so it looks to be an ongoing change.

Therefore, this issue still needs a proper fix.

bobberb · 2020-02-14T21:14:09Z

Arch LTS is now linux-lts 5.4.19-1 and DKMS will not install the module.

Whoops · 2020-02-14T21:43:33Z

@bobberb Are you using zfs-dkms from archzfs or something else?

I'm using zfs-dkms and update/rebooted this morning. Just double checked to verify, and I am on 5.4.19-1.

bobberb · 2020-02-14T21:53:57Z

Building zfs-dkms from the AUR, not downloading from the archzfs repo. Will try a reboot.

…

On Fri, Feb 14, 2020, 4:43 PM Walton Hoops ***@***.***> wrote: @bobberb <https://github.com/bobberb> Are you using zfs-dkms from archzfs <https://github.com/archzfs/archzfs> or something else? I'm using zfs-dkms and update/rebooted this morning. Just double checked to verify, and I am on 5.4.19-1. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9745>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAON37EXWZQVW6XPQ6N5TXLRC4GAVANCNFSM4J4RWSVQ> .

Whoops · 2020-02-14T22:39:24Z

Uh, if your ZFS is on root I wouldn't reboot till you've got a good kernel.
I know the aur-zfs and arch zfs are not the same, but I'm not sure the differences. I'd suggest switching to the zfs in the arch-zfs pacman repo. You can either install zfs-dkms and risk kernel breakage like we have now, or install the zfs-linux and zfs-linux-lts packages and it'll prevent you from updating to an unsupported kernel.

ipha · 2020-02-16T04:51:14Z

IMO the arch specific discussion is getting a bit off-topic,
In 5.4 zfs worked with CONFIG_PREEMPT=y and in 5.5+ it doesn't. Some distros ship this by default causing issues with 5.5+ kernels.

bobberb · 2020-02-16T05:05:23Z

My apologies.

…

On Sat, Feb 15, 2020, 11:51 PM Mitch Bigelow ***@***.***> wrote: IMO the arch specific discussion is getting a bit off-topic, In 5.4 zfs worked with CONFIG_PREEMPT=y and in 5.5+ it doesn't. Some distros ship this by default causing issues with 5.5+ kernels. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9745>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAON37EEBCR6AV56KHND5ALRDDA4LANCNFSM4J4RWSVQ> .

Commit torvalds/linux@9e8d42a0f accidentally converted the static inline function blkg_tryget() to GPL-only for kernels built with CONFIG_PREEMPT_RCU=y and CONFIG_BLK_CGROUP=y. Resolve the build issue by providing our own equivilant functionality when needed which uses rcu_read_lock_sched() internally as before. Signed-off-by: Brian Behlendorf <[email protected]> Issue openzfs#9745

Commit torvalds/linux@9e8d42a0f accidentally converted the static inline function blkg_tryget() to GPL-only for kernels built with CONFIG_PREEMPT_RCU=y and CONFIG_BLK_CGROUP=y. Resolve the build issue by providing our own equivalent functionality when needed which uses rcu_read_lock_sched() internally as before. Reviewed-by: Tony Hutter <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#9745 Closes openzfs#10072

behlendorf · 2020-02-28T17:22:04Z

A fix for this issue has been merged to the master branch and will be included in the next 0.8.x release. I've also backported a version of the patch which applies cleanly to 0.8.3 if you need the fix sooner, see 2fcab87.

eli-schwartz · 2020-02-28T17:36:37Z

I've also backported a version of the patch which applies cleanly to 0.8.3 if you need the fix sooner

Much appreciated!

(It would also be nice to get it more visibility by merging to maint.)

YaroKasear · 2020-02-28T17:39:07Z

Fantastic. Thanks for this fix. I got an update from the ArchZFS repository this morning, so I am going to recompile my custom kernel to see if that included the fix.

Commit torvalds/linux@9e8d42a0f accidentally converted the static inline function blkg_tryget() to GPL-only for kernels built with CONFIG_PREEMPT_RCU=y and CONFIG_BLK_CGROUP=y. Resolve the build issue by providing our own equivalent functionality when needed which uses rcu_read_lock_sched() internally as before. Reviewed-by: Tony Hutter <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#9745 Closes openzfs#10072

Commit torvalds/linux@9e8d42a0f accidentally converted the static inline function blkg_tryget() to GPL-only for kernels built with CONFIG_PREEMPT_RCU=y and CONFIG_BLK_CGROUP=y. Resolve the build issue by providing our own equivalent functionality when needed which uses rcu_read_lock_sched() internally as before. Reviewed-by: Tony Hutter <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #9745 Closes #10072

Commit torvalds/linux@9e8d42a0f accidentally converted the static inline function blkg_tryget() to GPL-only for kernels built with CONFIG_PREEMPT_RCU=y and CONFIG_BLK_CGROUP=y. Resolve the build issue by providing our own equivalent functionality when needed which uses rcu_read_lock_sched() internally as before. Reviewed-by: Tony Hutter <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#9745 Closes openzfs#10072 Signed-off-by: Pavel Snajdr <[email protected]>

Commit torvalds/linux@9e8d42a0f accidentally converted the static inline function blkg_tryget() to GPL-only for kernels built with CONFIG_PREEMPT_RCU=y and CONFIG_BLK_CGROUP=y. Resolve the build issue by providing our own equivalent functionality when needed which uses rcu_read_lock_sched() internally as before. Reviewed-by: Tony Hutter <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#9745 Closes openzfs#10072

behlendorf added the Type: Building Indicates an issue related to building binaries label Dec 18, 2019

This comment has been minimized.

Sign in to view

Ingramz mentioned this issue Feb 3, 2020

linux 5.5.1 breaks zfs archzfs/archzfs#328

Closed

mrhaoxx mentioned this issue Feb 5, 2020

Linux 5.3.0-rc4-rk3399: GPL-incompatible module zfs.ko uses GPL-only symbol 'preempt_schedule_notrace' #9948

Closed

This comment has been minimized.

Sign in to view

behlendorf changed the title ~~Cannot compile zfs for 5.5-rc2~~ Compile failure with Linux 5.5-rc2 and CONFIG_PREEMPT_RCU=y Feb 27, 2020

behlendorf mentioned this issue Feb 27, 2020

Linux 5.5 compat: blkg_tryget() #10072

Merged

12 tasks

behlendorf closed this as completed in bd0d24e Feb 28, 2020

johnramsden mentioned this issue Feb 29, 2020

can't mod probe zfs on 2020 release danboid/ALEZ#53

Closed

eli-schwartz mentioned this issue Apr 14, 2020

Linux 5.6 compat #9961

Closed

12 tasks

eadwu mentioned this issue May 4, 2020

zfs: fix build against PREEMPT NixOS/nixpkgs#86821

Closed

10 tasks

eli-schwartz mentioned this issue Aug 17, 2020

Patch-release branch #10722

Closed

satmandu mentioned this issue Sep 1, 2020

ZoL 0.7.13 + Linux Kernel 5.0.4: GPL-incompatible module zfs.ko uses GPL-only symbol 'preempt_schedule_notrace' #8545

Closed

jittygitty mentioned this issue May 17, 2022

ZFS grinds to a halt on Asahi while generating machine id when using luks device #13431

Open

Compile failure with Linux 5.5-rc2 and CONFIG_PREEMPT_RCU=y #9745

Compile failure with Linux 5.5-rc2 and CONFIG_PREEMPT_RCU=y #9745

Comments

artee666 commented Dec 18, 2019

Describe the problem you're observing

PrivatePuffin commented Dec 18, 2019

behlendorf commented Dec 19, 2019

artee666 commented Dec 19, 2019 • edited Loading

wolfgangwuerfl commented Dec 21, 2019 • edited Loading

This comment has been minimized.

XHDR commented Jan 10, 2020

PrivatePuffin commented Jan 10, 2020

XHDR commented Jan 10, 2020 • edited Loading

PrivatePuffin commented Jan 11, 2020 • edited Loading

freswa commented Jan 22, 2020

behlendorf commented Jan 22, 2020

tycho commented Jan 23, 2020

rkitover commented Jan 24, 2020

artee666 commented Jan 24, 2020 • edited Loading

behlendorf commented Jan 24, 2020

Lalufu commented Jan 31, 2020

ndowens commented Feb 3, 2020

rkitover commented Feb 3, 2020

tycho commented Feb 4, 2020

wavexx commented Feb 4, 2020 via email

YaroKasear commented Feb 4, 2020

ndowens commented Feb 4, 2020 via email

WoefulDerelict commented Feb 5, 2020 • edited Loading

dagaz commented Feb 5, 2020

francoism90 commented Feb 6, 2020 • edited Loading

artee666 commented Feb 6, 2020 • edited Loading

francoism90 commented Feb 8, 2020

jonathonf commented Feb 12, 2020 • edited Loading

dreamcat4 commented Feb 13, 2020 • edited Loading

jonathonf commented Feb 13, 2020

bobberb commented Feb 14, 2020 • edited Loading

Whoops commented Feb 14, 2020

bobberb commented Feb 14, 2020 via email

Whoops commented Feb 14, 2020

ipha commented Feb 16, 2020

bobberb commented Feb 16, 2020 via email

This comment has been minimized.

behlendorf commented Feb 28, 2020

eli-schwartz commented Feb 28, 2020 • edited Loading

YaroKasear commented Feb 28, 2020

artee666 commented Dec 19, 2019 •

edited

Loading

wolfgangwuerfl commented Dec 21, 2019 •

edited

Loading

XHDR commented Jan 10, 2020 •

edited

Loading

PrivatePuffin commented Jan 11, 2020 •

edited

Loading

artee666 commented Jan 24, 2020 •

edited

Loading

WoefulDerelict commented Feb 5, 2020 •

edited

Loading

francoism90 commented Feb 6, 2020 •

edited

Loading

artee666 commented Feb 6, 2020 •

edited

Loading

jonathonf commented Feb 12, 2020 •

edited

Loading

dreamcat4 commented Feb 13, 2020 •

edited

Loading

bobberb commented Feb 14, 2020 •

edited

Loading

eli-schwartz commented Feb 28, 2020 •

edited

Loading