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 bigeasy@linutronix.de Cc:: Borislav Petkov bp@suse.de Cc: Rik van Riel riel@surriel.com Cc: "H. Peter Anvin" hpa@zytor.com Cc: "Jason A. Donenfeld" Jason@zx2c4.com Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Dave Hansen dave.hansen@linux.intel.com Cc: Ingo Molnar mingo@redhat.com Cc: Nicolai Stange nstange@suse.de Cc: Paolo Bonzini pbonzini@redhat.com Cc: Radim Krčmář rkrcmar@redhat.com Cc: Thomas Gleixner tglx@linutronix.de Cc: x86@kernel.org Cc: stable@vger.kernel.org Fixes: 12209993e98c ("x86/fpu: Don't export __kernel_fpu_{begin,end}()") Signed-off-by: Andy Lutomirski luto@kernel.org ---
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):
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 bigeasy@linutronix.de Cc:: Borislav Petkov bp@suse.de Cc: Rik van Riel riel@surriel.com Cc: "H. Peter Anvin" hpa@zytor.com Cc: "Jason A. Donenfeld" Jason@zx2c4.com Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Dave Hansen dave.hansen@linux.intel.com Cc: Ingo Molnar mingo@redhat.com Cc: Nicolai Stange nstange@suse.de Cc: Paolo Bonzini pbonzini@redhat.com Cc: Radim Krčmář rkrcmar@redhat.com Cc: Thomas Gleixner tglx@linutronix.de Cc: x86@kernel.org Cc: stable@vger.kernel.org Fixes: 12209993e98c ("x86/fpu: Don't export __kernel_fpu_{begin,end}()") Signed-off-by: Andy Lutomirski luto@kernel.org
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 bigeasy@linutronix.de 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 bigeasy@linutronix.de Cc:: Borislav Petkov bp@suse.de Cc: Rik van Riel riel@surriel.com Cc: "H. Peter Anvin" hpa@zytor.com Cc: "Jason A. Donenfeld" Jason@zx2c4.com Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Dave Hansen dave.hansen@linux.intel.com Cc: Ingo Molnar mingo@redhat.com Cc: Nicolai Stange nstange@suse.de Cc: Paolo Bonzini pbonzini@redhat.com Cc: Radim Krčmář rkrcmar@redhat.com Cc: Thomas Gleixner tglx@linutronix.de Cc: x86@kernel.org Cc: stable@vger.kernel.org Fixes: 12209993e98c ("x86/fpu: Don't export __kernel_fpu_{begin,end}()") Signed-off-by: Andy Lutomirski luto@kernel.org
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.
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.
On May 3, 2019, at 11:07 AM, Borislav Petkov bp@alien8.de 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.)
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.
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 jikos@kernel.org 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 jikos@kernel.org 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 jikos@kernel.org 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... 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 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.
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,
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 :)
...
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)
linux-stable-mirror@lists.linaro.org
-
Andy Lutomirski -
Andy Lutomirski -
Borislav Petkov -
David Laight -
Greg KH -
Ingo Molnar -
Jiri Kosina -
Paolo Bonzini -
Rik van Riel -
Sebastian Andrzej Siewior -
Sebastian Gottschall