Compile failure with Linux 5.5-rc2 and CONFIG_PREEMPT_RCU=y

[artee666]

Distribution Name | Archlinux
Distribution Version | current
Linux Kernel | 5.5-rc2
Architecture | amd64
ZFS Version | 2019.12.13.r5590.gddb4e69db-1
SPL Version | 2019.12.13.r5590.gddb4e69db-1

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]

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]

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]

@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]

@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.

[PrivatePuffin]

guess the error comes

Well it isn't an error, it's linux' legally flawed way of putting licence additions into code, which may or may not be actually legally valid depending on the usecase.

Coding wise it should've been a warning, because stoping compile due to formalities just isn't best practice. But I guess it's easier to fix this than get gpl-fundementalism out of the linux codebase 👍

TL:DR
An error should be used for "Can't do", this is "Won't do". But thats kinda offtopic I guess.

[XHDR]

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]

@XHDR So basically: Cant reproduce?

[XHDR]

@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]

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]

@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]

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]

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]

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]

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.