Re: sched: some non-GPL symbols becoming GPL-only with CONFIG_PREEMPT_RT enabled

[Angelo Haller <lkml@szanni.org>]

On 28/11/2021 04.46, Oleksandr Natalenko wrote:
> Hello.
> 
> On neděle 28. listopadu 2021 1:07:49 CET Angelo Haller wrote:
>> Greetings. I hope I picked the right mailing list, as this issue might
>> be one that affects various subsystems and components:
>>
>> When compiling kernel 5.15 (and 5.16-rc2) with `CONFIG_PREEMPT_RT`
>> enabled, some of the symbols being exported as `EXPORT_SYMBOL` suddenly
>> become `EXPORT_SYMBOL_GPL` through transitive effects.
>>
>> In particular the symbols `migrate_enable` and `migrate_disable` are
>> currently marked as `EXPORT_SYMBOL_GPL` - yet are called from multiple
>> functions that are marked as `EXPORT_SYMBOL`.
>>
>> Here an (incomplete?) listing of call sites I came across:
>>
>> kernel/locking/spinlock_rt.c - rt_spin_unlock()
>> kernel/locking/spinlock_rt.c - rt_read_unlock()
>> kernel/locking/spinlock_rt.c - rt_write_unlock()
>> mm/highmem.c - kunmap_local_indexed()
>>
>> The issue I'm facing in particular is kmap_atomic() calling
>> `migrate_disable` and therefore suddenly becoming GPL-only. This breaks
>> the out-of-tree CDDL licensed module ZFS and has been reported before
>> already [0]. The conversation seemingly going nowhere - or patches at
>> least not being applied upstream. Downstream issue for reference [1].
> 
> What about going the other way around and let ZFS be re-licensed under GPL?
> 
That would be lovely but is unlikely to ever happen. Numerous people 
have tried over the years - many, including me, would love for ZFS to be 
mainlined but unless Oracle decides to re-license the original code this 
will most likely not happen [3].

This is not really the main issue I was trying to highlight though.
What I was highlighting is the fact that exported symbols change license 
depending on the kconfig!
This will randomly stop dkms modules from building depending on my (or 
my distributions) kconfig. To me as a user this effectively BREAKS user 
space.
And yes, I am aware exported symbols are not syscalls but I thought 
there was at least some type of stability guarantee within the same 
kernel version. Maybe my thoughts on that matter are incorrect though.

[3] https://github.com/openzfs/zfs/issues/8314
>> As the original implementation of `migrate_enable` and `migrate_disable`
>> is apparently by Peter Zijlstra [2]. Peter would you be willing to
>> re-license both symbols `migrate_enable` and `migrate_disable` as
>> `EXPORT_SYMBOL`?
>>
>> The bigger issue I'm seeing though is that there is currently no
>> automated test to uncover exported symbols changing their license
>> depending on build configuration? I am not intimately familiar with the
>> API guarantees the kernel gives, but this seems like a violation. There
>> might be other symbols with similar licensing problems.
>>
>> I can open a bugzilla ticket too - if that is preferred.
>>
>> Angelo
>>
>>
>> [0]
>> https://lore.kernel.org/linux-rt-users/20201208212841.694b3022@orivej.orivej
>> .org/T/ [1] https://github.com/openzfs/zfs/issues/11097
>> [2]
>> https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/diff/p
>> atches/0009-sched-Add-migrate_disable.patch?h=v5.9-rc8-rt14-patches&id=9a89b
>> fdb3bc77aecdd0ff8cc69b595541c7b50c4
> 
>