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/[email protected]/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
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/[email protected]
> .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)
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/[email protected]
>> .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
>
>