The FPU is not a super-Linuxy internal detail, so remove the _GPL
from its export. Without something like this patch, it's impossible
for even highly license-respecting non-GPL modules to use the FPU,
which seems silly to me. After all, the FPU is a CPU feature, not
really a kernel feature at all.
Cc: Sebastian Andrzej Siewior <[email protected]>
Cc:: Borislav Petkov <[email protected]>
Cc: Rik van Riel <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: "Jason A. Donenfeld" <[email protected]>
Cc: Ard Biesheuvel <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Nicolai Stange <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Cc: Radim Krčmář <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Cc: [email protected]
Fixes: 12209993e98c ("x86/fpu: Don't export __kernel_fpu_{begin,end}()")
Signed-off-by: Andy Lutomirski <[email protected]>
---
This fixes a genuine annoyance for ZFS on Linux. Regardless of what
one may think about the people who distribute ZFS on Linux
*binaries*, as far as I know, the source and the users who build it
themselves are entirely respectful of everyone's license. I have no
problem with EXPORT_SYMBOL_GPL() in general, but let's please avoid
using it for things that aren't fundamentally Linux internals.
arch/x86/kernel/fpu/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
index 2e5003fef51a..8de5687a470d 100644
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -127,14 +127,14 @@ void kernel_fpu_begin(void)
preempt_disable();
__kernel_fpu_begin();
}
-EXPORT_SYMBOL_GPL(kernel_fpu_begin);
+EXPORT_SYMBOL(kernel_fpu_begin);
void kernel_fpu_end(void)
{
__kernel_fpu_end();
preempt_enable();
}
-EXPORT_SYMBOL_GPL(kernel_fpu_end);
+EXPORT_SYMBOL(kernel_fpu_end);
/*
* Save the FPU state (mark it for reload if necessary):
--
2.21.0
On 2019-05-02 07:42:14 [-0700], Andy Lutomirski wrote:
> The FPU is not a super-Linuxy internal detail, so remove the _GPL
> from its export. Without something like this patch, it's impossible
> for even highly license-respecting non-GPL modules to use the FPU,
> which seems silly to me. After all, the FPU is a CPU feature, not
> really a kernel feature at all.
>
> Cc: Sebastian Andrzej Siewior <[email protected]>
> Cc:: Borislav Petkov <[email protected]>
> Cc: Rik van Riel <[email protected]>
> Cc: "H. Peter Anvin" <[email protected]>
> Cc: "Jason A. Donenfeld" <[email protected]>
> Cc: Ard Biesheuvel <[email protected]>
> Cc: Dave Hansen <[email protected]>
> Cc: Ingo Molnar <[email protected]>
> Cc: Nicolai Stange <[email protected]>
> Cc: Paolo Bonzini <[email protected]>
> Cc: Radim Krčmář <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Fixes: 12209993e98c ("x86/fpu: Don't export __kernel_fpu_{begin,end}()")
> Signed-off-by: Andy Lutomirski <[email protected]>
> ---
>
> This fixes a genuine annoyance for ZFS on Linux. Regardless of what
> one may think about the people who distribute ZFS on Linux
> *binaries*, as far as I know, the source and the users who build it
> themselves are entirely respectful of everyone's license. I have no
> problem with EXPORT_SYMBOL_GPL() in general, but let's please avoid
> using it for things that aren't fundamentally Linux internals.
Please don't start this. We have everything _GPL that is used for FPU
related code and only a few functions are exported because KVM needs it.
Also with the recent FPU rework it is much easier to get this wrong so I
would not want for any OOT code to mess with it.
And again: It does not change whether or not ZFS can be used on Linux
(excluding the license issue). They simply can't use crc32 with their
SSE assembly and this is it.
Sebastian
On Thu, May 2, 2019 at 8:41 AM Sebastian Andrzej Siewior
<[email protected]> wrote:
>
> On 2019-05-02 07:42:14 [-0700], Andy Lutomirski wrote:
> > The FPU is not a super-Linuxy internal detail, so remove the _GPL
> > from its export. Without something like this patch, it's impossible
> > for even highly license-respecting non-GPL modules to use the FPU,
> > which seems silly to me. After all, the FPU is a CPU feature, not
> > really a kernel feature at all.
> >
> > Cc: Sebastian Andrzej Siewior <[email protected]>
> > Cc:: Borislav Petkov <[email protected]>
> > Cc: Rik van Riel <[email protected]>
> > Cc: "H. Peter Anvin" <[email protected]>
> > Cc: "Jason A. Donenfeld" <[email protected]>
> > Cc: Ard Biesheuvel <[email protected]>
> > Cc: Dave Hansen <[email protected]>
> > Cc: Ingo Molnar <[email protected]>
> > Cc: Nicolai Stange <[email protected]>
> > Cc: Paolo Bonzini <[email protected]>
> > Cc: Radim Krčmář <[email protected]>
> > Cc: Thomas Gleixner <[email protected]>
> > Cc: [email protected]
> > Cc: [email protected]
> > Fixes: 12209993e98c ("x86/fpu: Don't export __kernel_fpu_{begin,end}()")
> > Signed-off-by: Andy Lutomirski <[email protected]>
> > ---
> >
> > This fixes a genuine annoyance for ZFS on Linux. Regardless of what
> > one may think about the people who distribute ZFS on Linux
> > *binaries*, as far as I know, the source and the users who build it
> > themselves are entirely respectful of everyone's license. I have no
> > problem with EXPORT_SYMBOL_GPL() in general, but let's please avoid
> > using it for things that aren't fundamentally Linux internals.
>
> Please don't start this. We have everything _GPL that is used for FPU
> related code and only a few functions are exported because KVM needs it.
> Also with the recent FPU rework it is much easier to get this wrong so I
> would not want for any OOT code to mess with it.
>
I'm not saying that we should export things for ZFS's benefit. But,
as far as I know, _GPL means "this interface is sufficiently specific
to Linux details that we think that any user must be a derived work".
I don't think that kernel_fpu_begin() is an example of that.
--Andy
On Thu, May 02, 2019 at 09:29:01AM -0700, Andy Lutomirski wrote:
> I'm not saying that we should export things for ZFS's benefit. But,
> as far as I know, _GPL means "this interface is sufficiently specific
> to Linux details that we think that any user must be a derived work".
> I don't think that kernel_fpu_begin() is an example of that.
But it is sufficiently specific. It is present on x86 and s390 only -
other arches don't have it.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On 02/05/19 10:55, Borislav Petkov wrote:
> On Thu, May 02, 2019 at 09:29:01AM -0700, Andy Lutomirski wrote:
>> I'm not saying that we should export things for ZFS's benefit. But,
>> as far as I know, _GPL means "this interface is sufficiently specific
>> to Linux details that we think that any user must be a derived work".
>> I don't think that kernel_fpu_begin() is an example of that.
> But it is sufficiently specific. It is present on x86 and s390 only -
> other arches don't have it.
This is not what is meant usually by "sufficiently specific to Linux
details". The questions to ask are:
1) Is it a Linux-only thing to run FPU or SIMD code in the kernel? The
answer is clearly no.
2) Is the API form tied to Linux's implementation of the FPU? I'd argue
that a simple begin/end pair is not (for example, on Windows you just
xsave at the beginning and xrstor at the end).
So I totally agree with Andy on this.
Your observation that the API only exists on x86 and s390 has no bearing
to whether the functions should be EXPORT_SYMBOL_GPL or EXPORT_SYMBOL.
ARM has kernel_neon_begin/end, PPC has enable/disable_kernel_altivec.
It's just that SIMD code is so arch-specific that nobody has bothered
unifying the namings (or, nobody considers the different names a problem
at all).
Paolo
On Fri, May 03, 2019 at 11:21:15AM -0600, Paolo Bonzini wrote:
> Your observation that the API only exists on x86 and s390 has no bearing
> to whether the functions should be EXPORT_SYMBOL_GPL or EXPORT_SYMBOL.
> ARM has kernel_neon_begin/end, PPC has enable/disable_kernel_altivec.
> It's just that SIMD code is so arch-specific that nobody has bothered
> unifying the namings (or, nobody considers the different names a problem
> at all).
This is actually proving my point: there wasn't any real agreement on
what interfaces should be immutable so that out-of-tree code can use
them and us guaranteeing they won't change. Instead, it was a random
thing that just happened.
So if you have to use them in some out-of-tree module, you'd have to
do arch-specific hackery, obviously, because each arch does different
things.
So what happened is that out-of-tree module simply grabbed them and now
when we change our implementation, we broke it. And I care about this
why exactly?
So let me cut to the chase: you and Andy are arguing about what exactly?
* We should support out-of-tree code in general?
* We should support out-of-tree code if/when <fill in the specifics which
out-of-tree code should be supported by Linux and which not>?
* We should be free to change kernel interfaces and implementation as
we see fit, without paying attention to some out-of-tree, probably
license-incompatible, maybe even proprietary code? (I don't think it is
that, though).
* Something else I've missed.
So before we waste any more time with this, let's agree on the rules
first: do we support out-of-tree code and if so, how much and to what
degree?
This keeps happening so I think we should write it all down so that it
is crystal clear to all parties involved what can and cannot be done.
And then when we all agree, we can enforce those rules and then act
accordingly when changing implementations.
Maybe it is written down somewhere but I haven't found it yet so if you
do, pls point me to it.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Fri, May 03, 2019 at 11:54:54AM -0700, Andy Lutomirski wrote:
> I don’t think I or has said we should try to make these interfaces
> immutable.
How else would you have a stable interface for OOT modules? If at all,
that is.
> What I’m saying is that, since we’re exporting the symbol anyway
> and it’s not particularly Linuxy, that we shouldn’t say that only
> *GPL* out-of-tree modules may use it. It seems like anyone who wants
> to put the effort into tracking which kernel has which symbols and is
> willing to accept the utter instability of the interface may use it.
This is just silly: when we change it next time, it'll be the same
crying again. No, we don't want to do that. This keeps happening with
all kinds of symbols being exported and unexported.
> So if we ever unexport the symbol entirely, I won’t object.
Yah, and you'll break them again. That's just unnecesary pain each time.
> I object to what I consider to be the inappropriate claim that it’s
> a *GPL* export.
Yes, that is the problem. Jiri alluded to it too - I don't think it is
clear to people involved - me included - what exports should be done and
how. And what assurances - if any - we're giving.
> (I actually hope we unexport it once simd_get() and friends land —
> they’re a much better API, and we should migrate over to it.)
Same problem as above with those.
That's why we need some sort of an explicit ruling all sides will adhere
to.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Thu, 2 May 2019, Sebastian Andrzej Siewior wrote:
> Please don't start this. We have everything _GPL that is used for FPU
> related code and only a few functions are exported because KVM needs it.
That's not completely true. There are a lot of static inlines out there,
which basically made it possible for external modules to use FPU (in some
way) when they had kernel_fpu_[begin|end]() available.
I personally don't care about ZFS a tiny little bit; but in general, the
current situation with _GPL and non-_GPL exports is simply not nice. It's
not really about licensing (despite the name), it's about 'internal vs
external', which noone is probably able to define properly.
If it would be strictly about license compatibility, that'd at least make
us somewhat deterministic.
--
Jiri Kosina
SUSE Labs
> On May 3, 2019, at 11:07 AM, Borislav Petkov <[email protected]> wrote:
>
>> On Fri, May 03, 2019 at 11:21:15AM -0600, Paolo Bonzini wrote:
>> Your observation that the API only exists on x86 and s390 has no bearing
>> to whether the functions should be EXPORT_SYMBOL_GPL or EXPORT_SYMBOL.
>> ARM has kernel_neon_begin/end, PPC has enable/disable_kernel_altivec.
>> It's just that SIMD code is so arch-specific that nobody has bothered
>> unifying the namings (or, nobody considers the different names a problem
>> at all).
>
> This is actually proving my point: there wasn't any real agreement on
> what interfaces should be immutable so that out-of-tree code can use
> them and us guaranteeing they won't change. Instead, it was a random
> thing that just happened.
>
I don’t think I or has said we should try to make these interfaces immutable. What I’m saying is that, since we’re exporting the symbol anyway and it’s not particularly Linuxy, that we shouldn’t say that only *GPL* out-of-tree modules may use it. It seems like anyone who wants to put the effort into tracking which kernel has which symbols and is willing to accept the utter instability of the interface may use it.
So if we ever unexport the symbol entirely, I won’t object. I object to what I consider to be the inappropriate claim that it’s a *GPL* export.
(I actually hope we unexport it once simd_get() and friends land — they’re a much better API, and we should migrate over to it.)
* Jiri Kosina <[email protected]> wrote:
> On Thu, 2 May 2019, Sebastian Andrzej Siewior wrote:
>
> > Please don't start this. We have everything _GPL that is used for FPU
> > related code and only a few functions are exported because KVM needs it.
>
> That's not completely true. There are a lot of static inlines out there,
> which basically made it possible for external modules to use FPU (in some
> way) when they had kernel_fpu_[begin|end]() available.
>
> I personally don't care about ZFS a tiny little bit; but in general, the
> current situation with _GPL and non-_GPL exports is simply not nice. It's
> not really about licensing (despite the name), it's about 'internal vs
> external', which noone is probably able to define properly.
But that's exactly what licensing *IS* about: the argument is that
'internal' interfaces are clear proof that the binary module is actually
a derived work of the kernel.
(Using regular exported symbols might still make a binary module derived
work, but it's less clear-cut.)
So don't be complicit with binary module authors who try to circumvent
the GPL by offloading the actual license violation to the end user ...
> If it would be strictly about license compatibility, that'd at least
> make us somewhat deterministic.
License compatibility is rarely deterministic to begin with, there's a
lot of grey area. Adding _GPL increases the likelihood that the module
using it has to be covered by the GPL too. In fact behavior of binary
modules seems to confirm that legal expectation: very few binary modules
are trying to circumvent _GPL symbols by ignoring the _GPL attribute.
Anyway, in terms of _GPL exports the policy has always been that if a
major author of the code asks for a symbol to be _GPL, then it should be
so, even if other authors have a different judgement.
Thanks,
Ingo
Am 04.05.2019 um 02:47 schrieb Ingo Molnar:
> * Jiri Kosina <[email protected]> wrote:
>
>> On Thu, 2 May 2019, Sebastian Andrzej Siewior wrote:
>>
>>> Please don't start this. We have everything _GPL that is used for FPU
>>> related code and only a few functions are exported because KVM needs it.
>> That's not completely true. There are a lot of static inlines out there,
>> which basically made it possible for external modules to use FPU (in some
>> way) when they had kernel_fpu_[begin|end]() available.
>>
>> I personally don't care about ZFS a tiny little bit; but in general, the
>> current situation with _GPL and non-_GPL exports is simply not nice. It's
>> not really about licensing (despite the name), it's about 'internal vs
>> external', which noone is probably able to define properly.
> But that's exactly what licensing *IS* about: the argument is that
> 'internal' interfaces are clear proof that the binary module is actually
> a derived work of the kernel.
Using fpu code in kernel space in a kernel module is a derived work of
the kernel itself?
dont get me wrong, but this is absurd. i mean you limit the use of cpu
instructions. the use
of cpu instructions should be free of any licensing issue. i would even
argument you are violating
the license of the cpu ower given to the kernel by executing it, by
restricting its use for no reason
Sebastian
On Sat, May 04, 2019 at 04:28:17AM +0200, Sebastian Gottschall wrote:
>
> Am 04.05.2019 um 02:47 schrieb Ingo Molnar:
> > * Jiri Kosina <[email protected]> wrote:
> >
> > > On Thu, 2 May 2019, Sebastian Andrzej Siewior wrote:
> > >
> > > > Please don't start this. We have everything _GPL that is used for FPU
> > > > related code and only a few functions are exported because KVM needs it.
> > > That's not completely true. There are a lot of static inlines out there,
> > > which basically made it possible for external modules to use FPU (in some
> > > way) when they had kernel_fpu_[begin|end]() available.
> > >
> > > I personally don't care about ZFS a tiny little bit; but in general, the
> > > current situation with _GPL and non-_GPL exports is simply not nice. It's
> > > not really about licensing (despite the name), it's about 'internal vs
> > > external', which noone is probably able to define properly.
> > But that's exactly what licensing *IS* about: the argument is that
> > 'internal' interfaces are clear proof that the binary module is actually
> > a derived work of the kernel.
> Using fpu code in kernel space in a kernel module is a derived work of the
> kernel itself?
> dont get me wrong, but this is absurd. i mean you limit the use of cpu
> instructions. the use
> of cpu instructions should be free of any licensing issue. i would even
> argument you are violating
> the license of the cpu ower given to the kernel by executing it, by
> restricting its use for no reason
Now you are just being crazy, please go talk to a lawyer about how the
GPL actually works.
If Andy wants to change the symbol of what he wrote from
EXPORT_SYMBOL_GPL() to EXPORT_SYMBOL(), that's fine, it's his option.
Any loony discussion about if this is actually a licensing issue or not
needs to just go to /dev/null
As homework, everyone please go read this:
http://softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL_Compliance_2d_ed.pdf
and remember that the license of the Linux kernel is GPLv2.
Now where's the "kill this thread" option on mutt so I don't have to see
any more of this nonsense...
greg k-h
On Fri, 3 May 2019, Jiri Kosina wrote:
> > Please don't start this. We have everything _GPL that is used for FPU
> > related code and only a few functions are exported because KVM needs it.
>
> That's not completely true. There are a lot of static inlines out there,
> which basically made it possible for external modules to use FPU (in some
> way) when they had kernel_fpu_[begin|end]() available.
... any for many uses that's really the only thing that's needed.
kernel_fpu_beign();
asm volatile ("some SSE2/AVX/... math");
kernel_fpu_end();
No other bits of the FPU API, so there is no way of getting anything wrong
because of FPU intrinsic details really.
So I don't really see a problem with Andy's patch. If we want to annoy
external non-GPL modules as much as possible, sure, that's for a separate
discussion though (and I am sure many people would agree to that).
Proposal to get rid of EXPORT_SYMBOL in favor of EXPORT_SYMBOL_GPL would
be a good start I guess :)
--
Jiri Kosina
SUSE Labs
On Sat, 2019-05-04 at 04:28 +0200, Sebastian Gottschall wrote:
> Using fpu code in kernel space in a kernel module is a derived work
> of
> the kernel itself?
> dont get me wrong, but this is absurd. i mean you limit the use of
> cpu
> instructions. the use
> of cpu instructions should be free of any licensing issue. i would
> even
> argument you are violating
> the license of the cpu ower given to the kernel by executing it, by
> restricting its use for no reason
Using FPU code in kernel space in a kernel module
does not require the use of kernel_fpu_begin/end().
The kernel module could simply disable preemption,
save the FPU registers, use the FPU, restore the
FPU registers, and reenable preemption.
However, using kernel_fpu_begin/end() does get that
module some nice optimizations that are specific to
Linux.
--
All Rights Reversed.
On Sun, 5 May 2019, Rik van Riel wrote:
> > Using fpu code in kernel space in a kernel module is a derived work of
> > the kernel itself? dont get me wrong, but this is absurd. i mean you
> > limit the use of cpu instructions. the use of cpu instructions should
> > be free of any licensing issue. i would even argument you are
> > violating the license of the cpu ower given to the kernel by executing
> > it, by restricting its use for no reason
>
> Using FPU code in kernel space in a kernel module does not require the
> use of kernel_fpu_begin/end().
>
> The kernel module could simply disable preemption, save the FPU
> registers, use the FPU, restore the FPU registers, and reenable
> preemption.
That means the module basically reimplemented kernel_fpu_begin/end() in
its whole (not getting the further optimizations implemented by the
kernel, sure). And therefore I sort of don't see the point of "hiding" it.
Thanks,
--
Jiri Kosina
SUSE Labs
...
> So I don't really see a problem with Andy's patch. If we want to annoy
> external non-GPL modules as much as possible, sure, that's for a separate
> discussion though (and I am sure many people would agree to that).
> Proposal to get rid of EXPORT_SYMBOL in favor of EXPORT_SYMBOL_GPL would
> be a good start I guess :)
As a writer on an external non-GPL module I'd point out:
1 - Even if we wanted to 'upstream' our code it is very specific
and wouldn't really be wanted/accepted.
Even if accepted it would always be excluded from builds.
2 - It would take man-years to make it meet the kernel code guidelines
and to make it portable (from x86).
It also contains conditionals because it gets build for windows.
I don't like a lot of it.
3 - Almost all the calls to kernel functions are through a 'wrapper'
file that is compiled on the target system.
About the only functions that are directly called are ones like memcpy().
4 - It wouldn't be that hard, and would still be GPLv2 if we built
two loadable modules, one GPL and one non-GPL and put all our
wrapper functions in the GPL one.
We'd still need a small wrapper for the non-GPL module, but while
Non-GPL modules are supported at all it wouldn't be much work.
5 - The continual tweaks for new kernel versions keep us in a job!
Some of the _GPL exports are a PITA:
- we can't reference count network namespaces (without creating a socket).
- we can't reference count 'pid' structures making sending signals tricky.
- I thing the PCIe error handling functions that we ought to be using
are GPL.
At the moment we've not needed the fpu :-)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Am 07.05.2019 um 12:31 schrieb David Laight:
> ...
>> So I don't really see a problem with Andy's patch. If we want to annoy
>> external non-GPL modules as much as possible, sure, that's for a separate
>> discussion though (and I am sure many people would agree to that).
>> Proposal to get rid of EXPORT_SYMBOL in favor of EXPORT_SYMBOL_GPL would
>> be a good start I guess :)
> As a writer on an external non-GPL module I'd point out:
> 1 - Even if we wanted to 'upstream' our code it is very specific
> and wouldn't really be wanted/accepted.
> Even if accepted it would always be excluded from builds.
> 2 - It would take man-years to make it meet the kernel code guidelines
> and to make it portable (from x86).
> It also contains conditionals because it gets build for windows.
> I don't like a lot of it.
> 3 - Almost all the calls to kernel functions are through a 'wrapper'
> file that is compiled on the target system.
> About the only functions that are directly called are ones like memcpy().
> 4 - It wouldn't be that hard, and would still be GPLv2 if we built
> two loadable modules, one GPL and one non-GPL and put all our
> wrapper functions in the GPL one.
> We'd still need a small wrapper for the non-GPL module, but while
> Non-GPL modules are supported at all it wouldn't be much work.
> 5 - The continual tweaks for new kernel versions keep us in a job!
>
> Some of the _GPL exports are a PITA:
> - we can't reference count network namespaces (without creating a socket).
> - we can't reference count 'pid' structures making sending signals tricky.
> - I thing the PCIe error handling functions that we ought to be using
> are GPL.
>
> At the moment we've not needed the fpu :-)
>
> David
unfortunatly some does like ZFS which is opensource, but just licensed
under the wrong copyleft license which cannot be changed that easy.
but its a big loss for the community if such projects get blocked or
limited by a singe linux developer. but thats just my own oppinion (even
if not intentionally targeted here of course).
not every project on his planet is a nvidia driver blob. whats most
important for me is not if its GPL or not. most important is that its
opensource and copyleft.
so the question is if it isnt possible to create a EXPORT_SYMBOL variant
which includes acceptable license models, but still restricts
unacceptable licenses
Sebastian
On Wed, May 08, 2019 at 02:28:21PM +0200, Sebastian Gottschall wrote:
> so the question is if it isnt possible to create a EXPORT_SYMBOL variant
> which includes acceptable license models, but still restricts unacceptable
> licenses
It's not very difficult, "acceptable" license models are all described
in the kernel LICENSES/ directory, and must be GPLv2 compatible.
greg k-h