FATAL: modpost: GPL-incompatible module zzstd.ko uses GPL-only symbol 'mutex_lock_nested'

[cheesycod]

FATAL: modpost: GPL-incompatible module zzstd.ko uses GPL-only symbol 'mutex_lock_nested'
This only occurs on Linux 5.9-rc6. Linux 5.8 is not affected

[cheesycod]

I had to edit META in order to get it to build

[cheesycod]

And uhhh... the zstd is BSD licensed meaning you also need to edit that as well

[cheesycod]

This doesnt happen on 5.8

[PrivatePuffin]

@cheesycod Please try and actually fill in the form next time, it's there to be sure you give all information in one go instead of feeling the need to add 3 follow-up oneliners. (which makes things harder to figure out for everyone ;) )

That being said:
@BrainSlayer I think you might want to take a look :)

zzstd.ko == zfs_zstd.c, right?

Which is actually un-altered and dual-licenced BSD-GPLv2, so should be able to use GPL-only symbols.

I think I know why this is triggering:
Linus added his anti-nvidia shit, which tries to track if modules that reference other modules stick to their in-code GPL limitations.

[cheesycod]

Even changing the zstd license doesn't fully solve the problem as the resulting module fails to load mutex_lock_nested and some other symbols with error 2

[PrivatePuffin]

@cheesycod I know, I already explained why that wouldnt work.

I think I know why this is triggering:
Linus added his anti-nvidia shit, which tries to track if modules that reference other modules stick to their in-code GPL limitations.

[behlendorf]

@cheesycod this is likely caused by having CONFIG_DEBUG_LOCK_ALLOC defined in your kernel build. It's often defined for -debug kernels, for example the Fedora, RHEL, and CentOS kernels all define it by default in their debug kernels. You shouldn't have an issue if you use a kernel without this defined.

This is something of a long standing annoyance. You just happen to get the warning with zstd since license string wasn't recognized as a known one. "Dual BSD/GPL" is what the kernel expects for a BSD license, we can update the module accordingly.

https://github.com/torvalds/linux/blob/master/include/linux/module.h#L182-L226

[cheesycod]

@behlendorf I get another issue happened on a nodebug kernel without CONFIG_DEBUG_LOCK_ALLOC set

[cheesycod]

On the nodebug kernel, it compiles but fails to load the module due to undefined symbol: mutex_lock_nested error=2

[cheesycod]

https://ibb.co/LS70XbD
If you need a screenshot of the link error

[PrivatePuffin]

ErrorS you mean ;-)

[BrainSlayer]

this is a overall problem in zfs if you enable lockdep debugging in kernel. its not just zzstd. its also zfs.ko. its not fixable due the license of zfs

[BrainSlayer]

i can recheck it with 5.9 but this must be resolved in zfs overall. i cannot fix this, since i need the mutex functions

[PrivatePuffin]

Sorry, wasn't aware @BrainSlayer and @behlendorf !
Can we at least document this one and the other "problematic compile flags"?

[cheesycod]

this is a overall problem in zfs if you enable lockdep debugging in kernel. its not just zzstd. its also zfs.ko. its not fixable due the license of zfs

Once again, this is on a nodebug kernel without lockdep debugging. Older versions of ZFS from August work perfectly

[BrainSlayer]

i just can say this problem isnt a zstd specific problem. the same symbols are used overall in zfs and i know this problem from older kernels with some specific debugging options. now in 5.9 i know what the kernel developers explicit want to prevent projects like zfs to use certain symbols. i havent checked the latest 5.9 tree yet. but will

[PrivatePuffin]

@BrainSlayer Yes, thats what I was thinking, maybe that measure is increasing the problem, I know that said code should be included in last 5.9 RC.

@cheesycod You could try two RC versions of kernel 5.9 back, If my theory increases the issue you will see said RC+zfs working just fine ;)

[cheesycod]

One question, what's stopping us from lying to the kernel and telling it we are GPL when we are really CDDL? It looks like it would solve a lot of headaches.

[PrivatePuffin]

@cheesycod Decency mostly.
There isn't even a clause in the GPL that allows developers to do what the Linux kernel is doing. It could even be considered a GPL violation itself.

So legally speaking there is no direct consequence in lying about your licence. It isn't more or less of a violation by adding a gpl flag to the code (because there is no legal requirement, or definition that justifies GPL flags to begin with)

There are two things keeping us from doing this:

1. it's not be considered "okey" within the GPL community to do so and we don't want to alienate good developers even if they can considered to be "GPL fundementalists".
2. Setting a GPL flag when you are not, can be used in an american court as evidence of willfully violating a licence. Which is the jurisdiction most of the leadership and consumers of OpenZFS reside.

[cheesycod]

If Linus makes things worse, we might have to......

[PrivatePuffin]

@cheesycod I don't think it's needed to go there, yet.
But that has been previously discussed as one of the options in the future, yes.

[behlendorf]

Can we at least document this one and the other "problematic compile flags"?

We did. There was a configure time check added to detect this, unfortunately it appears it was accidental broken when integrating the parallel kABI checks. I've opened #10991 to fix the configure check.

@cheesycod based on the screenshot you provided it looks to me like your kernel is built with CONFIG_DEBUG_LOCK_ALLOC . Some of the symbols being called shouldn't exist if it's not defined. Would you mind applying the patch from #10991 to see if it detects the option now at configure time.