Support ZFS_CONFIG=m in kernel source tree

[schreiberstein]

System information

Type	Version/Name
Distribution Name	Debian GNU/Linux
Distribution Version	Stable/Stretch (10)
Linux Kernel	5.4.72
Architecture	amd64
ZFS Version	0.8.5
SPL Version	0.8.5

Describe the problem you're observing

Building the ZFS On Linux modules via kernel source tree integration (--enable-linux-builtin=yes) fails because zfs.ko uses a GPL-only symbol (trace_seq_printf).

Describe how to reproduce the problem

• Integrate ZFS on Linux into Kernel source tree
• Add "CONFIG_ZFS=m" to Kernel .config file
• Build kernel

Include any warning/errors/backtraces from the system logs

FATAL: modpost: GPL-incompatible module zfs.ko uses GPL-only symbol 'trace_seq_printf'
make[4]: *** [scripts/Makefile.modpost:94: __modpost] Error 1
make[3]: *** [Makefile:1319: modules] Error 2
make[3]: *** Waiting for unfinished jobs....

Note: No, CONFIG_PREEMPT is not set.

Do you know if there is a quick fix for this?

Thank you very much!
schreiberstein

[behlendorf]

This isn't a symbol ZFS uses directly, nor is it something we've seen with the automated --enable-linux-builtin=yes testing done by the CI. It's probably being indirectly included due to another CONFIG_ option which is set in your kernel build. As a quick fix it looks like disabling CONFIG_TRACING should avoid the issue. Are you able to reproduce this with the stock Debian kernel config, are there custom CONFIG_ kernel options you're setting which might help us narrow it down.

[schreiberstein]

Hello!

Since Debian apparently never used the 5.4 series, I have built against the Ubuntu 20.04 LTS 5.4 Kernel config.
There I ended up with : FATAL: modpost: GPL-incompatible module zfs.ko uses GPL-only symbol 'perf_trace_buf_alloc'

I have difficulties finding a way to definitely disable CONFIG_TRACING.
There is some kind of dependency that turns CONFIG_TRACING on again even if I set it to =n or # xx is not set in the config and I cannot find it in menuconfig.

Is there a way to skip this check? Ubuntu redistributes ZFS kernel module binaries that they build out-of-tree and I guess they contain the same GPL-only symbols, but no error is thrown. So, I do not think it would make a (legal) difference to skip this check. And oddly enough, when I select ZFS as built-in to the kernel (not module), there is no warning or error at all, even though this is even "worse" in terms of CDDL-GPL-mixing.

EDIT: I found the original config for 5.4 (backport) and will try again shortly. Will update this ticket accordingly.

[schreiberstein]

This was the official Debian Backports Kernel 5.4 for Debian Stable (Buster):
https://snapshot.debian.org/package/linux-signed-amd64/5.4.19%2B1~bpo10%2B1/#kernel-image-5.4.0-0.bpo.4-amd64-di_5.4.19-1:7e:bpo10:2b:1

I stripped the config from the distribution signing key path for modules before loading it.
I copied the config, made "make olddefconfig" and "make bindeb-pkg".
It still fails with:

Kernel: arch/x86/boot/bzImage is ready  (#1)
FATAL: modpost: GPL-incompatible module zfs.ko uses GPL-only symbol 'perf_trace_buf_alloc'
make[4]: *** [scripts/Makefile.modpost:94: __modpost] Error 1
make[3]: *** [Makefile:1319: modules] Error 2
make[2]: *** [debian/rules:6: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
make[1]: *** [scripts/Makefile.package:83: bindeb-pkg] Error 2
make: *** [Makefile:1464: bindeb-pkg] Error 2

config-debian54-bp.txt

Am I doing something wrong here?
Could you provide me with a working config from your CI system?

Thank you very much.
schreiberstein

[behlendorf]

Can you check if HAVE_DECLARE_EVENT_CLASS is defined in zfs_config.h. After running configure run the following. It should be undefined. If it's not, you can manually update the zfs_config.h file to undefine it then try building.

$ grep HAVE_DECLARE_EVENT_CLASS zfs_config.h
/* #undef HAVE_DECLARE_EVENT_CLASS */

Assuming that's the case we'll need to determine why it was set wrong for this kernel. Can you attach the contents of the build/conftest/build.log file, it should have the results of that configure test which checks this.

[schreiberstein]

Thank you for your reply!

Indeed, include/zfs/zfs_config.h has the EVENT_CLASS defined:

linux-5.4.74# grep HAVE_DECLARE_EVENT_CLASS include/zfs/zfs_config.h
#define HAVE_DECLARE_EVENT_CLASS 1

Attached you find the file you have asked for - and additionally the entire config.log.
conftest-build-log.txt
zfs-config-log.txt

I commented out the offending line, but now it fails on a different one:

Kernel: arch/x86/boot/bzImage is ready  (#1)
FATAL: modpost: GPL-incompatible module zfs.ko uses GPL-only symbol 'kfree_call_rcu'
make[4]: *** [scripts/Makefile.modpost:94: __modpost] Error 1
make[3]: *** [Makefile:1319: modules] Error 2
make[2]: *** [debian/rules:6: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
make[1]: *** [scripts/Makefile.package:83: bindeb-pkg] Error 2
make: *** [Makefile:1464: bindeb-pkg] Error 2

[IvanVolosyuk]

What's the point in copying zfs sources into kernel with --enable-linux-builtin=yes
and using it as a module without:
CONFIG_ZFS=y

Just compile it in your custom kernel - problem solved.

[behlendorf]

Oh, I somehow missed the fact that you're building this in to the kernel with CONFIG_ZFS=m. This isn't currently supported and is why the ./configure checks are returning the wrong results. I'd suggest either building ZFS directly in to your kernel with CONFIG_ZFS=y, or building ZFS externally with the kernel development headers after building the kernel.

[schreiberstein]

Oh, I somehow missed the fact that you're building this in to the kernel with CONFIG_ZFS=m. This isn't currently supported and is why the ./configure checks are returning the wrong results. I'd suggest either building ZFS directly in to your kernel with CONFIG_ZFS=y, or building ZFS externally with the kernel development headers after building the kernel.

Thank you very much for your reply!
I would prefer to build ZFS as a module so that module parameters can be set during the modprobe configuration instead of the kernel commandline.

I am working on an embedded system which is built using a custom build system and its unified EFI binary kernel commandline should not need to be adjusted for each system in case I need a different ARC cache size or something else or simply want to load ZFS on demand.

If MODPOST fails because zfs.ko uses GPL-ONLY symbols, doesn't that mean that if I build the ZFS modules manually, that it also uses GPL-ONLY symbols without telling me about it, since this Kernel check script is not being run?
I am just trying to keep things as legal as possible.

I have yet to find out how distributions like Ubuntu do it, since zfs.ko is also included in their regular linux-image-amd64 generic configuration.

If ZFS On Linux will always use GPL-ONLY symbols regardless and is only caught "red handed" by some random kernel script, then I would just use "#define ZFS_META_LICENSE "GPL" to circumvent the check.

[behlendorf]

We're careful not to use any GPL-only symbols in OpenZFS. In order to detect which symbols are license compatible the configure script relies on the kernel generated Module.symvers file. The crux of the issue is that file is generated as part of the kernel build, so until you build the kernel once OpenZFS can't easily check which symbols are compatible. When the --enable-linux-builtin option is set we instead assume that if a function prototype is available then it's also compatible. As you discovered that's not always going to be the case which is why you ran in to the modpost failures.

If you don't mind an extra step what can do is build your kernel first without OpenZFS patched in as you would normally configure it. This will generate the needed Module.symvers file for your custom kernel build. Then you can run the OpenZFS ./configure script without the --enable-linux-builtin option to generate a compatible zfs_config.h file which is what you need. From there you can use the copy-builtin script as usual to apply the OpenZFS sources and compatible zfs_config.h to the kernel tree. If you don't often change your kernel or it's configuration you should be able to continue to use this same zfs_config.h.

[schreiberstein]

Thank you for your thorough explanation. Now I understand what the problem is. I will try that out (copying zfs_config.h) once I need this functionality.
It would be neat if proper detection could be added at some point in the future, if it is even possible. :-)
I wish the Kernel developers would put ideology aside and just expose all symbols as compatible. This GPL-ONLY stuff is bizarre in my opinion.

[schreiberstein]

We're careful not to use any GPL-only symbols in OpenZFS. In order to detect which symbols are license compatible the configure script relies on the kernel generated Module.symvers file. The crux of the issue is that file is generated as part of the kernel build, so until you build the kernel once OpenZFS can't easily check which symbols are compatible. When the --enable-linux-builtin option is set we instead assume that if a function prototype is available then it's also compatible. As you discovered that's not always going to be the case which is why you ran in to the modpost failures.

If you don't mind an extra step what can do is build your kernel first without OpenZFS patched in as you would normally configure it. This will generate the needed Module.symvers file for your custom kernel build. Then you can run the OpenZFS ./configure script without the --enable-linux-builtin option to generate a compatible zfs_config.h file which is what you need. From there you can use the copy-builtin script as usual to apply the OpenZFS sources and compatible zfs_config.h to the kernel tree. If you don't often change your kernel or it's configuration you should be able to continue to use this same zfs_config.h.

Hello! I can confirm that your suggested workaround (copying zfs_config.h) works very well!
I have tested it on the most recent Kernel 5.9.11 release.

Thank you very much!