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

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

[Angelo Haller]

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

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/patches/0009-sched-Add-migrate_disable.patch?h=v5.9-rc8-rt14-patches&id=9a89bfdb3bc77aecdd0ff8cc69b595541c7b50c4

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

[Oleksandr Natalenko]

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?

> 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


-- 
Oleksandr Natalenko (post-factum)

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

[Angelo Haller]

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