linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export
@ 2019-05-02 14:42 Andy Lutomirski
  2019-05-02 15:40 ` Sebastian Andrzej Siewior
  0 siblings, 1 reply; 18+ messages in thread
From: Andy Lutomirski @ 2019-05-02 14:42 UTC (permalink / raw)
  To: Greg KH
  Cc: LKML, Andy Lutomirski, Sebastian Andrzej Siewior, Rik van Riel,
	H. Peter Anvin, Jason A. Donenfeld, Ard Biesheuvel, Dave Hansen,
	Ingo Molnar, Nicolai Stange, Paolo Bonzini,
	Radim Krčmář,
	Thomas Gleixner, x86, stable

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):
-- 
2.21.0


^ permalink raw reply related	[flat|nested] 18+ messages in thread

* Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export
  2019-05-02 14:42 [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export Andy Lutomirski
@ 2019-05-02 15:40 ` Sebastian Andrzej Siewior
  2019-05-02 16:29   ` Andy Lutomirski
  2019-05-03 18:49   ` Jiri Kosina
  0 siblings, 2 replies; 18+ messages in thread
From: Sebastian Andrzej Siewior @ 2019-05-02 15:40 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Greg KH, LKML, Rik van Riel, H. Peter Anvin, Jason A. Donenfeld,
	Ard Biesheuvel, Dave Hansen, Ingo Molnar, Nicolai Stange,
	Paolo Bonzini, Radim Krčmář,
	Thomas Gleixner, x86, stable

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export
  2019-05-02 15:40 ` Sebastian Andrzej Siewior
@ 2019-05-02 16:29   ` Andy Lutomirski
  2019-05-02 16:55     ` Borislav Petkov
  2019-05-03 18:49   ` Jiri Kosina
  1 sibling, 1 reply; 18+ messages in thread
From: Andy Lutomirski @ 2019-05-02 16:29 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior
  Cc: Andy Lutomirski, Greg KH, LKML, Rik van Riel, H. Peter Anvin,
	Jason A. Donenfeld, Ard Biesheuvel, Dave Hansen, Ingo Molnar,
	Nicolai Stange, Paolo Bonzini, Radim Krčmář,
	Thomas Gleixner, X86 ML, stable

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export
  2019-05-02 16:29   ` Andy Lutomirski
@ 2019-05-02 16:55     ` Borislav Petkov
  2019-05-03 17:21       ` Paolo Bonzini
  0 siblings, 1 reply; 18+ messages in thread
From: Borislav Petkov @ 2019-05-02 16:55 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Sebastian Andrzej Siewior, Greg KH, LKML, Rik van Riel,
	H. Peter Anvin, Jason A. Donenfeld, Ard Biesheuvel, Dave Hansen,
	Ingo Molnar, Nicolai Stange, Paolo Bonzini,
	Radim Krčmář,
	Thomas Gleixner, X86 ML, stable

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.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export
  2019-05-02 16:55     ` Borislav Petkov
@ 2019-05-03 17:21       ` Paolo Bonzini
  2019-05-03 18:07         ` Borislav Petkov
  0 siblings, 1 reply; 18+ messages in thread
From: Paolo Bonzini @ 2019-05-03 17:21 UTC (permalink / raw)
  To: Borislav Petkov, Andy Lutomirski
  Cc: Sebastian Andrzej Siewior, Greg KH, LKML, Rik van Riel,
	H. Peter Anvin, Jason A. Donenfeld, Ard Biesheuvel, Dave Hansen,
	Ingo Molnar, Nicolai Stange, Radim Krčmář,
	Thomas Gleixner, X86 ML, stable

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export
  2019-05-03 17:21       ` Paolo Bonzini
@ 2019-05-03 18:07         ` Borislav Petkov
  2019-05-03 18:54           ` Andy Lutomirski
  0 siblings, 1 reply; 18+ messages in thread
From: Borislav Petkov @ 2019-05-03 18:07 UTC (permalink / raw)
  To: Paolo Bonzini
  Cc: Andy Lutomirski, Sebastian Andrzej Siewior, Greg KH, LKML,
	Rik van Riel, H. Peter Anvin, Jason A. Donenfeld, Ard Biesheuvel,
	Dave Hansen, Ingo Molnar, Nicolai Stange,
	Radim Krčmář,
	Thomas Gleixner, X86 ML, stable

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.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export
  2019-05-02 15:40 ` Sebastian Andrzej Siewior
  2019-05-02 16:29   ` Andy Lutomirski
@ 2019-05-03 18:49   ` Jiri Kosina
  2019-05-04  0:47     ` Ingo Molnar
  2019-05-04  7:26     ` Jiri Kosina
  1 sibling, 2 replies; 18+ messages in thread
From: Jiri Kosina @ 2019-05-03 18:49 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior
  Cc: Andy Lutomirski, Greg KH, LKML, Rik van Riel, H. Peter Anvin,
	Jason A. Donenfeld, Ard Biesheuvel, Dave Hansen, Ingo Molnar,
	Nicolai Stange, Paolo Bonzini, Radim Krčmář,
	Thomas Gleixner, x86, stable, Jiri Kosina

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


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export
  2019-05-03 18:07         ` Borislav Petkov
@ 2019-05-03 18:54           ` Andy Lutomirski
  2019-05-03 19:07             ` Borislav Petkov
  0 siblings, 1 reply; 18+ messages in thread
From: Andy Lutomirski @ 2019-05-03 18:54 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Paolo Bonzini, Andy Lutomirski, Sebastian Andrzej Siewior,
	Greg KH, LKML, Rik van Riel, H. Peter Anvin, Jason A. Donenfeld,
	Ard Biesheuvel, Dave Hansen, Ingo Molnar, Nicolai Stange,
	Radim Krčmář,
	Thomas Gleixner, X86 ML, stable


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



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export
  2019-05-03 18:54           ` Andy Lutomirski
@ 2019-05-03 19:07             ` Borislav Petkov
  0 siblings, 0 replies; 18+ messages in thread
From: Borislav Petkov @ 2019-05-03 19:07 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Paolo Bonzini, Andy Lutomirski, Sebastian Andrzej Siewior,
	Greg KH, LKML, Rik van Riel, H. Peter Anvin, Jason A. Donenfeld,
	Ard Biesheuvel, Dave Hansen, Ingo Molnar, Nicolai Stange,
	Radim Krčmář,
	Thomas Gleixner, X86 ML, stable

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.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export
  2019-05-03 18:49   ` Jiri Kosina
@ 2019-05-04  0:47     ` Ingo Molnar
  2019-05-04  2:28       ` Sebastian Gottschall
  2019-05-04  7:26     ` Jiri Kosina
  1 sibling, 1 reply; 18+ messages in thread
From: Ingo Molnar @ 2019-05-04  0:47 UTC (permalink / raw)
  To: Jiri Kosina
  Cc: Sebastian Andrzej Siewior, Andy Lutomirski, Greg KH, LKML,
	Rik van Riel, H. Peter Anvin, Jason A. Donenfeld, Ard Biesheuvel,
	Dave Hansen, Ingo Molnar, Nicolai Stange, Paolo Bonzini,
	Radim Krčmář,
	Thomas Gleixner, x86, stable, Jiri Kosina


* 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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export
  2019-05-04  0:47     ` Ingo Molnar
@ 2019-05-04  2:28       ` Sebastian Gottschall
  2019-05-04  6:40         ` Greg KH
  2019-05-05 16:05         ` Rik van Riel
  0 siblings, 2 replies; 18+ messages in thread
From: Sebastian Gottschall @ 2019-05-04  2:28 UTC (permalink / raw)
  To: Ingo Molnar, Jiri Kosina
  Cc: Sebastian Andrzej Siewior, Andy Lutomirski, Greg KH, LKML,
	Rik van Riel, H. Peter Anvin, Jason A. Donenfeld, Ard Biesheuvel,
	Dave Hansen, Ingo Molnar, Nicolai Stange, Paolo Bonzini,
	Radim Krčmář,
	Thomas Gleixner, x86, stable, Jiri Kosina


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



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export
  2019-05-04  2:28       ` Sebastian Gottschall
@ 2019-05-04  6:40         ` Greg KH
  2019-05-05 16:05         ` Rik van Riel
  1 sibling, 0 replies; 18+ messages in thread
From: Greg KH @ 2019-05-04  6:40 UTC (permalink / raw)
  To: Sebastian Gottschall
  Cc: Ingo Molnar, Jiri Kosina, Sebastian Andrzej Siewior,
	Andy Lutomirski, LKML, Rik van Riel, H. Peter Anvin,
	Jason A. Donenfeld, Ard Biesheuvel, Dave Hansen, Ingo Molnar,
	Nicolai Stange, Paolo Bonzini, Radim Krčmář,
	Thomas Gleixner, x86, stable, Jiri Kosina

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export
  2019-05-03 18:49   ` Jiri Kosina
  2019-05-04  0:47     ` Ingo Molnar
@ 2019-05-04  7:26     ` Jiri Kosina
  2019-05-07 10:31       ` David Laight
  1 sibling, 1 reply; 18+ messages in thread
From: Jiri Kosina @ 2019-05-04  7:26 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior
  Cc: Andy Lutomirski, Greg KH, LKML, Rik van Riel, H. Peter Anvin,
	Jason A. Donenfeld, Ard Biesheuvel, Dave Hansen, Ingo Molnar,
	Nicolai Stange, Paolo Bonzini, Radim Krčmář,
	Thomas Gleixner, x86, stable

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


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export
  2019-05-04  2:28       ` Sebastian Gottschall
  2019-05-04  6:40         ` Greg KH
@ 2019-05-05 16:05         ` Rik van Riel
  2019-05-05 19:09           ` Jiri Kosina
  1 sibling, 1 reply; 18+ messages in thread
From: Rik van Riel @ 2019-05-05 16:05 UTC (permalink / raw)
  To: Sebastian Gottschall, Ingo Molnar, Jiri Kosina
  Cc: Sebastian Andrzej Siewior, Andy Lutomirski, Greg KH, LKML,
	H. Peter Anvin, Jason A. Donenfeld, Ard Biesheuvel, Dave Hansen,
	Ingo Molnar, Nicolai Stange, Paolo Bonzini,
	Radim Krčmář,
	Thomas Gleixner, x86, stable, Jiri Kosina

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export
  2019-05-05 16:05         ` Rik van Riel
@ 2019-05-05 19:09           ` Jiri Kosina
  0 siblings, 0 replies; 18+ messages in thread
From: Jiri Kosina @ 2019-05-05 19:09 UTC (permalink / raw)
  To: Rik van Riel
  Cc: Sebastian Gottschall, Ingo Molnar, Sebastian Andrzej Siewior,
	Andy Lutomirski, Greg KH, LKML, H. Peter Anvin,
	Jason A. Donenfeld, Ard Biesheuvel, Dave Hansen, Ingo Molnar,
	Nicolai Stange, Paolo Bonzini, Radim Krčmář,
	Thomas Gleixner, x86, stable, Jiri Kosina

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


^ permalink raw reply	[flat|nested] 18+ messages in thread

* RE: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export
  2019-05-04  7:26     ` Jiri Kosina
@ 2019-05-07 10:31       ` David Laight
  2019-05-08 12:28         ` Sebastian Gottschall
  0 siblings, 1 reply; 18+ messages in thread
From: David Laight @ 2019-05-07 10:31 UTC (permalink / raw)
  To: 'Jiri Kosina', Sebastian Andrzej Siewior
  Cc: Andy Lutomirski, Greg KH, LKML, Rik van Riel, H. Peter Anvin,
	Jason A. Donenfeld, Ard Biesheuvel, Dave Hansen, Ingo Molnar,
	Nicolai Stange, Paolo Bonzini, Radim Krčmář,
	Thomas Gleixner, x86, stable

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


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export
  2019-05-07 10:31       ` David Laight
@ 2019-05-08 12:28         ` Sebastian Gottschall
  2019-05-08 12:51           ` Greg KH
  0 siblings, 1 reply; 18+ messages in thread
From: Sebastian Gottschall @ 2019-05-08 12:28 UTC (permalink / raw)
  To: David Laight, 'Jiri Kosina', Sebastian Andrzej Siewior
  Cc: Andy Lutomirski, Greg KH, LKML, Rik van Riel, H. Peter Anvin,
	Jason A. Donenfeld, Ard Biesheuvel, Dave Hansen, Ingo Molnar,
	Nicolai Stange, Paolo Bonzini, Radim Krčmář,
	Thomas Gleixner, x86, stable


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


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export
  2019-05-08 12:28         ` Sebastian Gottschall
@ 2019-05-08 12:51           ` Greg KH
  0 siblings, 0 replies; 18+ messages in thread
From: Greg KH @ 2019-05-08 12:51 UTC (permalink / raw)
  To: Sebastian Gottschall
  Cc: David Laight, 'Jiri Kosina',
	Sebastian Andrzej Siewior, Andy Lutomirski, LKML, Rik van Riel,
	H. Peter Anvin, Jason A. Donenfeld, Ard Biesheuvel, Dave Hansen,
	Ingo Molnar, Nicolai Stange, Paolo Bonzini,
	Radim Krčmář,
	Thomas Gleixner, x86, stable

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2019-05-08 12:51 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-02 14:42 [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export Andy Lutomirski
2019-05-02 15:40 ` Sebastian Andrzej Siewior
2019-05-02 16:29   ` Andy Lutomirski
2019-05-02 16:55     ` Borislav Petkov
2019-05-03 17:21       ` Paolo Bonzini
2019-05-03 18:07         ` Borislav Petkov
2019-05-03 18:54           ` Andy Lutomirski
2019-05-03 19:07             ` Borislav Petkov
2019-05-03 18:49   ` Jiri Kosina
2019-05-04  0:47     ` Ingo Molnar
2019-05-04  2:28       ` Sebastian Gottschall
2019-05-04  6:40         ` Greg KH
2019-05-05 16:05         ` Rik van Riel
2019-05-05 19:09           ` Jiri Kosina
2019-05-04  7:26     ` Jiri Kosina
2019-05-07 10:31       ` David Laight
2019-05-08 12:28         ` Sebastian Gottschall
2019-05-08 12:51           ` Greg KH

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).