Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Marc Dionne]

On Thu, Dec 27, 2018 at 11:20 AM Linux Kernel Mailing List
<linux-kernel@vger.kernel.org> wrote:
>
> Commit:     12209993e98c5fa1855c467f22a24e3d5b8be205
> Parent:     2f2fcc40a961ed04f0e130803fbaa868c2899310
> Refname:    refs/heads/master
> Web:        https://git.kernel.org/torvalds/c/12209993e98c5fa1855c467f22a24e3d5b8be205
> Author:     Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> AuthorDate: Thu Nov 29 16:02:10 2018 +0100
> Committer:  Borislav Petkov <bp@suse.de>
> CommitDate: Tue Dec 4 12:37:28 2018 +0100
>
>     x86/fpu: Don't export __kernel_fpu_{begin,end}()
>
>     There is one user of __kernel_fpu_begin() and before invoking it,
>     it invokes preempt_disable(). So it could invoke kernel_fpu_begin()
>     right away. The 32bit version of arch_efi_call_virt_setup() and
>     arch_efi_call_virt_teardown() does this already.
>
>     The comment above *kernel_fpu*() claims that before invoking
>     __kernel_fpu_begin() preemption should be disabled and that KVM is a
>     good example of doing it. Well, KVM doesn't do that since commit
>
>       f775b13eedee2 ("x86,kvm: move qemu/guest FPU switching out to vcpu_run")
>
>     so it is not an example anymore.
>
>     With EFI gone as the last user of __kernel_fpu_{begin|end}(), both can
>     be made static and not exported anymore.
>
>     Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>     Signed-off-by: Borislav Petkov <bp@suse.de>
>     Reviewed-by: Rik van Riel <riel@surriel.com>
>     Cc: "H. Peter Anvin" <hpa@zytor.com>
>     Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
>     Cc: Andy Lutomirski <luto@kernel.org>
>     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: kvm ML <kvm@vger.kernel.org>
>     Cc: linux-efi <linux-efi@vger.kernel.org>
>     Cc: x86-ml <x86@kernel.org>
>     Link: https://lkml.kernel.org/r/20181129150210.2k4mawt37ow6c2vq@linutronix.de
> ---
>  arch/x86/include/asm/efi.h     |  6 ++----
>  arch/x86/include/asm/fpu/api.h | 15 +++++----------
>  arch/x86/kernel/fpu/core.c     |  6 ++----
>  3 files changed, 9 insertions(+), 18 deletions(-)
>
> diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
> index eea40d52ca78..45864898f7e5 100644
> --- a/arch/x86/include/asm/efi.h
> +++ b/arch/x86/include/asm/efi.h
> @@ -82,8 +82,7 @@ struct efi_scratch {
>  #define arch_efi_call_virt_setup()                                     \
>  ({                                                                     \
>         efi_sync_low_kernel_mappings();                                 \
> -       preempt_disable();                                              \
> -       __kernel_fpu_begin();                                           \
> +       kernel_fpu_begin();                                             \
>         firmware_restrict_branch_speculation_start();                   \
>                                                                         \
>         if (!efi_enabled(EFI_OLD_MEMMAP))                               \
> @@ -99,8 +98,7 @@ struct efi_scratch {
>                 efi_switch_mm(efi_scratch.prev_mm);                     \
>                                                                         \
>         firmware_restrict_branch_speculation_end();                     \
> -       __kernel_fpu_end();                                             \
> -       preempt_enable();                                               \
> +       kernel_fpu_end();                                               \
>  })
>
>  extern void __iomem *__init efi_ioremap(unsigned long addr, unsigned long size,
> diff --git a/arch/x86/include/asm/fpu/api.h b/arch/x86/include/asm/fpu/api.h
> index a9caac9d4a72..b56d504af654 100644
> --- a/arch/x86/include/asm/fpu/api.h
> +++ b/arch/x86/include/asm/fpu/api.h
> @@ -12,17 +12,12 @@
>  #define _ASM_X86_FPU_API_H
>
>  /*
> - * Careful: __kernel_fpu_begin/end() must be called with preempt disabled
> - * and they don't touch the preempt state on their own.
> - * If you enable preemption after __kernel_fpu_begin(), preempt notifier
> - * should call the __kernel_fpu_end() to prevent the kernel/user FPU
> - * state from getting corrupted. KVM for example uses this model.
> - *
> - * All other cases use kernel_fpu_begin/end() which disable preemption
> - * during kernel FPU usage.
> + * Use kernel_fpu_begin/end() if you intend to use FPU in kernel context. It
> + * disables preemption so be careful if you intend to use it for long periods
> + * of time.
> + * If you intend to use the FPU in softirq you need to check first with
> + * irq_fpu_usable() if it is possible.
>   */
> -extern void __kernel_fpu_begin(void);
> -extern void __kernel_fpu_end(void);
>  extern void kernel_fpu_begin(void);
>  extern void kernel_fpu_end(void);
>  extern bool irq_fpu_usable(void);
> diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
> index 2ea85b32421a..2e5003fef51a 100644
> --- a/arch/x86/kernel/fpu/core.c
> +++ b/arch/x86/kernel/fpu/core.c
> @@ -93,7 +93,7 @@ bool irq_fpu_usable(void)
>  }
>  EXPORT_SYMBOL(irq_fpu_usable);
>
> -void __kernel_fpu_begin(void)
> +static void __kernel_fpu_begin(void)
>  {
>         struct fpu *fpu = &current->thread.fpu;
>
> @@ -111,9 +111,8 @@ void __kernel_fpu_begin(void)
>                 __cpu_invalidate_fpregs_state();
>         }
>  }
> -EXPORT_SYMBOL(__kernel_fpu_begin);
>
> -void __kernel_fpu_end(void)
> +static void __kernel_fpu_end(void)
>  {
>         struct fpu *fpu = &current->thread.fpu;
>
> @@ -122,7 +121,6 @@ void __kernel_fpu_end(void)
>
>         kernel_fpu_enable();
>  }
> -EXPORT_SYMBOL(__kernel_fpu_end);
>
>  void kernel_fpu_begin(void)
>  {

This commit removes an exported function pair that is currently used
by out of tree modules, while the replacement pair
(kernel_fpu_begin/end) is EXPORT_SYMBOL_GPL.  So this is making
existing functionality GPL only, which will probably be an issue for
several out of tree modules that use the fpu.

Could kernel_fpu_begin/end be made plain EXPORT_SYMBOL?

Marc

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Sebastian Andrzej Siewior]

On 2019-01-07 18:08:26 [-0400], Marc Dionne wrote:
> On Thu, Dec 27, 2018 at 11:20 AM Linux Kernel Mailing List
> <linux-kernel@vger.kernel.org> wrote:
> >
> > Commit:     12209993e98c5fa1855c467f22a24e3d5b8be205
> >     x86/fpu: Don't export __kernel_fpu_{begin,end}()
> >
…
> >     With EFI gone as the last user of __kernel_fpu_{begin|end}(), both can
> >     be made static and not exported anymore.
> >
> This commit removes an exported function pair that is currently used
> by out of tree modules, while the replacement pair
> (kernel_fpu_begin/end) is EXPORT_SYMBOL_GPL.  So this is making
> existing functionality GPL only, which will probably be an issue for
> several out of tree modules that use the fpu.
> 
> Could kernel_fpu_begin/end be made plain EXPORT_SYMBOL?

It can be used by OOT modules as long as they are not under a
proprietary license. The change here is not for me to decide, I added
the x86 maintainers to make their decision. I can make a patch if they
say so.

On the other hand could we just drop EXPORT_SYMBOL_GPL? I doubt this
helps in any way yet please correct me if I am wrong. 
The kernel is GPL and everything links to it should be GPL compatible. People
that don't specify a GPL compatible license either use wrapper around their
binary blob or use EXPORT_SYMBOL functions. The latter group complains each
time a function is not available anymore and we end up changing it to
EXPORT_SYMBOL.
So what do we gain from that EXPORT_SYMBOL_GPL?

> Marc

Sebastian

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Greg Kroah-Hartman]

On Wed, Jan 09, 2019 at 12:19:52PM +0100, Sebastian Andrzej Siewior wrote:
> On 2019-01-07 18:08:26 [-0400], Marc Dionne wrote:
> > On Thu, Dec 27, 2018 at 11:20 AM Linux Kernel Mailing List
> > <linux-kernel@vger.kernel.org> wrote:
> > >
> > > Commit:     12209993e98c5fa1855c467f22a24e3d5b8be205
> > >     x86/fpu: Don't export __kernel_fpu_{begin,end}()
> > >
> …
> > >     With EFI gone as the last user of __kernel_fpu_{begin|end}(), both can
> > >     be made static and not exported anymore.
> > >
> > This commit removes an exported function pair that is currently used
> > by out of tree modules, while the replacement pair
> > (kernel_fpu_begin/end) is EXPORT_SYMBOL_GPL.  So this is making
> > existing functionality GPL only, which will probably be an issue for
> > several out of tree modules that use the fpu.
> > 
> > Could kernel_fpu_begin/end be made plain EXPORT_SYMBOL?
> 
> It can be used by OOT modules as long as they are not under a
> proprietary license. The change here is not for me to decide, I added
> the x86 maintainers to make their decision. I can make a patch if they
> say so.

If there are no in-kernel users, the symbols should not be exported
anymore.  That's nothing new, we have always done this.

> On the other hand could we just drop EXPORT_SYMBOL_GPL? I doubt this
> helps in any way yet please correct me if I am wrong. 

Yes, it helps, please leave it as-is.

thanks,

greg k-h

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Sebastian Andrzej Siewior]

On 2019-01-09 17:52:35 [+0100], Greg Kroah-Hartman wrote:
> If there are no in-kernel users, the symbols should not be exported
> anymore.  That's nothing new, we have always done this.

The thing is that we had
  EXPORT_SYMBOL(__kernel_fpu_begin)
  EXPORT_SYMBOL_GPL(kernel_fpu_begin)

and now __kernel_fpu_begin() is no longer exported and static only.
All in kernel user (including the kvm module) use kernel_fpu_begin()
which is not available to proprietary modules. Hence Marc's mail.

> > On the other hand could we just drop EXPORT_SYMBOL_GPL? I doubt this
> > helps in any way yet please correct me if I am wrong. 
> 
> Yes, it helps, please leave it as-is.

As you say. I only notice that certain things used to work and then no
longer do because due to $rework it somehow become EXPORT_SYMBOL_GPL
only and people complain and we tend to switch the export back to
EXPORT_SYMBOL. I'm not aware of a case where it actually helped in
anyway.

> thanks,
> 
> greg k-h

Sebastian

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Marc Dionne]

On Wed, Jan 9, 2019 at 1:09 PM Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
>
> On 2019-01-09 17:52:35 [+0100], Greg Kroah-Hartman wrote:
> > If there are no in-kernel users, the symbols should not be exported
> > anymore.  That's nothing new, we have always done this.
>
> The thing is that we had
>   EXPORT_SYMBOL(__kernel_fpu_begin)
>   EXPORT_SYMBOL_GPL(kernel_fpu_begin)
>
> and now __kernel_fpu_begin() is no longer exported and static only.
> All in kernel user (including the kvm module) use kernel_fpu_begin()
> which is not available to proprietary modules. Hence Marc's mail.
>
> > > On the other hand could we just drop EXPORT_SYMBOL_GPL? I doubt this
> > > helps in any way yet please correct me if I am wrong.
> >
> > Yes, it helps, please leave it as-is.
>
> As you say. I only notice that certain things used to work and then no
> longer do because due to $rework it somehow become EXPORT_SYMBOL_GPL
> only and people complain and we tend to switch the export back to
> EXPORT_SYMBOL. I'm not aware of a case where it actually helped in
> anyway.
>
> > thanks,
> >
> > greg k-h
>
> Sebastian

I would point out that there are several precedents for restoring
exports after functionality has been unintentionally made GPL only;
from a quick lookup these are some examples:

  8af190958059 ("x86/paravirt: Remove GPL from pv_ops export")
  31c5bda3a656 ("mm: fix exports that inadvertently make put_page()
EXPORT_SYMBOL_GPL")
  1e5476815fd7 ("x86/tlb: Drop the _GPL from the cpu_tlbstate export")
  b562c171cf01 ("locking/refcounts: Do not force refcount_t usage as
GPL-only export")

Marc

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Greg Kroah-Hartman]

On Wed, Jan 09, 2019 at 01:40:14PM -0400, Marc Dionne wrote:
> On Wed, Jan 9, 2019 at 1:09 PM Sebastian Andrzej Siewior
> <bigeasy@linutronix.de> wrote:
> >
> > On 2019-01-09 17:52:35 [+0100], Greg Kroah-Hartman wrote:
> > > If there are no in-kernel users, the symbols should not be exported
> > > anymore.  That's nothing new, we have always done this.
> >
> > The thing is that we had
> >   EXPORT_SYMBOL(__kernel_fpu_begin)
> >   EXPORT_SYMBOL_GPL(kernel_fpu_begin)
> >
> > and now __kernel_fpu_begin() is no longer exported and static only.
> > All in kernel user (including the kvm module) use kernel_fpu_begin()
> > which is not available to proprietary modules. Hence Marc's mail.
> >
> > > > On the other hand could we just drop EXPORT_SYMBOL_GPL? I doubt this
> > > > helps in any way yet please correct me if I am wrong.
> > >
> > > Yes, it helps, please leave it as-is.
> >
> > As you say. I only notice that certain things used to work and then no
> > longer do because due to $rework it somehow become EXPORT_SYMBOL_GPL
> > only and people complain and we tend to switch the export back to
> > EXPORT_SYMBOL. I'm not aware of a case where it actually helped in
> > anyway.
> >
> > > thanks,
> > >
> > > greg k-h
> >
> > Sebastian
> 
> I would point out that there are several precedents for restoring
> exports after functionality has been unintentionally made GPL only;
> from a quick lookup these are some examples:
> 
>   8af190958059 ("x86/paravirt: Remove GPL from pv_ops export")
>   31c5bda3a656 ("mm: fix exports that inadvertently make put_page()
> EXPORT_SYMBOL_GPL")
>   1e5476815fd7 ("x86/tlb: Drop the _GPL from the cpu_tlbstate export")
>   b562c171cf01 ("locking/refcounts: Do not force refcount_t usage as
> GPL-only export")

Yes, but this is a bit different of a thing here.  The symbol you wish
to have changed was not modified at all, you just lost access to an
internal function that was fixed up and removed.

Best of luck,

greg k-h

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Greg Kroah-Hartman]

On Wed, Jan 09, 2019 at 06:09:35PM +0100, Sebastian Andrzej Siewior wrote:
> On 2019-01-09 17:52:35 [+0100], Greg Kroah-Hartman wrote:
> > If there are no in-kernel users, the symbols should not be exported
> > anymore.  That's nothing new, we have always done this.
> 
> The thing is that we had
>   EXPORT_SYMBOL(__kernel_fpu_begin)
>   EXPORT_SYMBOL_GPL(kernel_fpu_begin)
> 
> and now __kernel_fpu_begin() is no longer exported and static only.

Ok, that is fine.

> All in kernel user (including the kvm module) use kernel_fpu_begin()
> which is not available to proprietary modules. Hence Marc's mail.

But since when did out-of-tree modules use __kernel_fpu_begin?  It's an
x86-only thing, and shouldn't really be used by anyone, right?

> > > On the other hand could we just drop EXPORT_SYMBOL_GPL? I doubt this
> > > helps in any way yet please correct me if I am wrong. 
> > 
> > Yes, it helps, please leave it as-is.
> 
> As you say. I only notice that certain things used to work and then no
> longer do because due to $rework it somehow become EXPORT_SYMBOL_GPL
> only and people complain and we tend to switch the export back to
> EXPORT_SYMBOL.

That is a different topic than the whole _GPL symbol export at all.
Please don't conflate the two.

> I'm not aware of a case where it actually helped in anyway.

The use of the _GPL symbol exports has helped in numerous places over
the years.  I'd be glad to discuss details over a beverage sometime :)

thanks,

greg k-h

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Hutter, Tony]

> But since when did out-of-tree modules use __kernel_fpu_begin?  It's an
> x86-only thing, and shouldn't really be used by anyone, right?

ZFS on Linux uses it for checksums.  Its removal is currently breaking ZFS builds against 5.0:

https://github.com/zfsonlinux/zfs/issues/8259#issuecomment-452902510

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Sebastian Andrzej Siewior]

On 2019-01-10 17:32:58 [+0000], Hutter, Tony wrote:
> > But since when did out-of-tree modules use __kernel_fpu_begin?  It's an
> > x86-only thing, and shouldn't really be used by anyone, right?
> 
> ZFS on Linux uses it for checksums.  Its removal is currently breaking ZFS builds against 5.0:

So btrfs uses crc32c() / kernel's crypto API for that and ZFS can't?
Well the crypto API is GPL only exported so that won't work. crc32c() is
EXPORT_SYMBOL() so it would work.
On the other hand it does not look right to provide a EXPORT_SYMBOL
wrapper around a GPL only interface…

Sebastian

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Greg Kroah-Hartman]

On Thu, Jan 10, 2019 at 07:07:52PM +0100, Sebastian Andrzej Siewior wrote:
> On 2019-01-10 17:32:58 [+0000], Hutter, Tony wrote:
> > > But since when did out-of-tree modules use __kernel_fpu_begin?  It's an
> > > x86-only thing, and shouldn't really be used by anyone, right?
> > 
> > ZFS on Linux uses it for checksums.  Its removal is currently breaking ZFS builds against 5.0:
> 
> So btrfs uses crc32c() / kernel's crypto API for that and ZFS can't?
> Well the crypto API is GPL only exported so that won't work. crc32c() is
> EXPORT_SYMBOL() so it would work.
> On the other hand it does not look right to provide a EXPORT_SYMBOL
> wrapper around a GPL only interface…

Yes, the "GPL condom" attempt doesn't work at all.  It's been shot down
a long time ago in the courts.

My tolerance for ZFS is pretty non-existant.  Sun explicitly did not
want their code to work on Linux, so why would we do extra work to get
their code to work properly?

greg k-h

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Kash Pande]

[-- Attachment #1.1: Type: text/plain, Size: 1591 bytes --]


> Yes, the "GPL condom" attempt doesn't work at all.  It's been shot down
> a long time ago in the courts.

SFLC maintains there is no kernel licensing issue[1].

As a side note, even Hellwig's suit against VMware was dismissed (he may
appeal)[2].

Debian and Canonical base their decision to ship DKMS source for ZFS on
Linux[3].

The GPL does not disqualify a user from compiling ZFS or Linux however
they see fit.
It is only the users' distribution rights that come into question.

No one is combing ZFS into Linux or even distributing binary modules here;
we're following the terms of GPL.

> My tolerance for ZFS is pretty non-existant.  Sun explicitly did not
> want their code to work on Linux, so why would we do extra work to get
> their code to work properly?

1. Should your personal feelings affect the quality of the Linux kernel?
I say no.

2. Did Sun or Oracle ever release any statement of any kind that backs
your statement?

3. What extra work is being done here aside from the dropping of a
pseudo-protection,
the "GPL ONLY" symbol export? Something tells me, even if someone else
did "the work"
and submitted patches, you would find a reason to tell them to get
stuffed and leave
it "as-is".


With all of that... why have ANY kind of tolerance for out of tree
kernel modules at all?


[1] https://www.softwarefreedom.org/resources/2016/linux-kernel-cddl.html

[2] https://opensource.com/law/16/8/gpl-enforcement-action-hellwig-v-vmware

[3] https://lists.debian.org/debian-devel-announce/2015/04/msg00006.html






[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Lukas Wunner]

On Thu, Jan 10, 2019 at 07:24:13PM +0100, Greg Kroah-Hartman wrote:
> My tolerance for ZFS is pretty non-existant.  Sun explicitly did not
> want their code to work on Linux, so why would we do extra work to get
> their code to work properly?

ZoL facilitates seamless r/w cross-mounting with macOS, something no
other filesystem allows, and that feature is critical for me to work
on Linux drivers for Mac hardware.  Please don't make life harder than
necessary for developers like me.  Your "extra work" argument seems
disingenuous to me, Sebastian's patch is causing extra work for
ZFS developers, not the kernel community.  The maintenance burden
for the kernel community to retain the export is zero.

I respectfully ask for 12209993e98c to be reverted, or alternatively
amended to keep ZoL working.

Thanks,

Lukas

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Greg Kroah-Hartman]

On Fri, Jan 11, 2019 at 06:04:07AM +0100, Lukas Wunner wrote:
> On Thu, Jan 10, 2019 at 07:24:13PM +0100, Greg Kroah-Hartman wrote:
> > My tolerance for ZFS is pretty non-existant.  Sun explicitly did not
> > want their code to work on Linux, so why would we do extra work to get
> > their code to work properly?
> 
> ZoL facilitates seamless r/w cross-mounting with macOS, something no
> other filesystem allows, and that feature is critical for me to work
> on Linux drivers for Mac hardware.  Please don't make life harder than
> necessary for developers like me.  Your "extra work" argument seems
> disingenuous to me, Sebastian's patch is causing extra work for
> ZFS developers, not the kernel community.  The maintenance burden
> for the kernel community to retain the export is zero.

Sorry, no, we do not keep symbols exported for no in-kernel users.

greg k-h

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Lukas Wunner]

[cc += Ingo]

On Fri, Jan 11, 2019 at 06:40:58AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Jan 11, 2019 at 06:04:07AM +0100, Lukas Wunner wrote:
> > On Thu, Jan 10, 2019 at 07:24:13PM +0100, Greg Kroah-Hartman wrote:
> > > My tolerance for ZFS is pretty non-existant.  Sun explicitly did not
> > > want their code to work on Linux, so why would we do extra work to get
> > > their code to work properly?
> > 
> > ZoL facilitates seamless r/w cross-mounting with macOS, something no
> > other filesystem allows, and that feature is critical for me to work
> > on Linux drivers for Mac hardware.  Please don't make life harder than
> > necessary for developers like me.  Your "extra work" argument seems
> > disingenuous to me, Sebastian's patch is causing extra work for
> > ZFS developers, not the kernel community.  The maintenance burden
> > for the kernel community to retain the export is zero.
> 
> Sorry, no, we do not keep symbols exported for no in-kernel users.

AFAICS the only other alternative would be to remove the _GPL from
the export of kernel_fpu_begin()/end().  Those functions were static
inlines until v4.2 when Ingo uninlined them with commit d63e79b114c0
(x86/fpu: Uninline kernel_fpu_begin()/end()).

Ingo, why did you choose _GPL back then, given that the functions
were not restricted to GPL before?  Any objections to making them
available to non-GPL again?

As it stands, v5.0 removes the ability from non-GPL modules to use
the FPU or SIMD instructions and that kills ZFS on Linux.  This isn't
hurting Oracle, they're not using OpenZFS, it's only hurting ZoL users.

Thanks,

Lukas

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Pavel Machek]

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

On Fri 2019-01-11 06:40:58, Greg Kroah-Hartman wrote:
> On Fri, Jan 11, 2019 at 06:04:07AM +0100, Lukas Wunner wrote:
> > On Thu, Jan 10, 2019 at 07:24:13PM +0100, Greg Kroah-Hartman wrote:
> > > My tolerance for ZFS is pretty non-existant.  Sun explicitly did not
> > > want their code to work on Linux, so why would we do extra work to get
> > > their code to work properly?
> > 
> > ZoL facilitates seamless r/w cross-mounting with macOS, something no
> > other filesystem allows, and that feature is critical for me to work
> > on Linux drivers for Mac hardware.  Please don't make life harder than
> > necessary for developers like me.  Your "extra work" argument seems
> > disingenuous to me, Sebastian's patch is causing extra work for
> > ZFS developers, not the kernel community.  The maintenance burden
> > for the kernel community to retain the export is zero.
> 
> Sorry, no, we do not keep symbols exported for no in-kernel users.

Killing ZFS is _not_ nice. Its not like ZFS is closed source... 
 
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Rene Schickbauer]

On 10.01.19 19:24, Greg Kroah-Hartman wrote:

Dear Greg!

> My tolerance for ZFS is pretty non-existant.  Sun explicitly did not
> want their code to work on Linux, so why would we do extra work to get
> their code to work properly?

I'm not a kernel developer. I'm an application developer and system 
administrator. I'm also an Open Source advocate who regularly holds 
talks at Austrias biggest Linux conference in Graz.

Usually i'm not too interested in the internals of Linux kernel 
development, but this issue affects me on many levels.

ZFS brings me a lot of features, convenience and, most important of all, 
stability and reliability that i'm missing in other Linux filesystems.

ZFS on Linux is open source, made by people who invest their time and 
money into creating and maintaining a great filesystem. How can you say 
they are wrong in doing so?

To be frank, your argument, which boils down to "GPL is the only correct 
open source license", makes me ashamed to have been advocating people 
switching to Linux. This is exactly the kind of argument that made me 
switch away from closed source operating systems like Windows, only then 
it was Steve Ballmer using it against open source.

I understand that different open source licenses have different 
mindsets. But that doesn't make those other licenses any less valid. 
They still give us developers the freedom to learn, the freedom to build 
great systems, the freedom to change the world for the better. Not every 
project is able, or willing, to adopt the GPL. (I, for one, release my 
software under Perls Artistic license, because the GPL is too 
restrictive for my purpose).

So, please try to understand that non-GPL open source is still a useful 
resource for many of us out there. Maybe it helps to remember that Linux 
might never have existed if Linus Torvalds had never had the ability to 
experiment with the Minix source code and got inspired by it to write 
something more capable.

As for ZFS and me, ZFS is rather important to my work. If push comes to 
shove, i'm more inclined to switching to FreeBSD than to switch to 
another filesystem at this point in time. But i'm really hoping that 
this issue will get resolved by allowing to continue using non-GPL open 
source in Linux.

Sincerely,
Rene Schickbauer

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Christoph Hellwig]

Hi Rene,

please switch to FreeBSD instead of advocating to violate the copyright
and licensing rule on my and others work.

Thanks you!

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Greg Kroah-Hartman]

On Tue, Jan 15, 2019 at 02:01:48PM +0100, Rene Schickbauer wrote:
> To be frank, your argument, which boils down to "GPL is the only correct
> open source license", makes me ashamed to have been advocating people
> switching to Linux. This is exactly the kind of argument that made me switch
> away from closed source operating systems like Windows, only then it was
> Steve Ballmer using it against open source.

What?

No, my argument is, "If you want to interact directly with Linux kernel
code in kernel-space, then you have to abide by it's license, which is
GPLv2".  That's it.  If you wish to use open source code by another
license, wonderful, I'm not telling you what you can, and can not do,
but please, do not violate the license of the code I contributed under
GPLv2.

ZFS could be the best filesystem ever to grace this planet, that's
fantastic, but given that the creators of that code placed it under a
license that was specifically designed to not be compatible with Linux
to prevent it from ever being used on Linux, well, you can see why I
really don't care about it.  Why would I?

Those copyright owners (well license owner at this point in time) could
fix this all tomorrow if they wanted to.  But they do not, so _THEY_ are
the people you should be upset at.  Not at the Linux kernel developers
who are giving you a kernel on which to use on your systems, for free,
under the GPLv2.  Our position has always been very clear and upfront.
And really, so has the ZFS license creators.  So why is anyone upset
about all of this?  Nothing new has changed here with the license of
anything.

best of luck!

greg k-h

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Kash Pande]

[-- Attachment #1.1: Type: text/plain, Size: 3208 bytes --]

On 2019-01-15 5:42 a.m., Greg Kroah-Hartman wrote:
> On Tue, Jan 15, 2019 at 02:01:48PM +0100, Rene Schickbauer wrote:
>> To be frank, your argument, which boils down to "GPL is the only correct
>> open source license", makes me ashamed to have been advocating people
>> switching to Linux. This is exactly the kind of argument that made me switch
>> away from closed source operating systems like Windows, only then it was
>> Steve Ballmer using it against open source.
> What?
>
> No, my argument is, "If you want to interact directly with Linux kernel
> code in kernel-space, then you have to abide by it's license, which is
> GPLv2".  That's it.  If you wish to use open source code by another
> license, wonderful, I'm not telling you what you can, and can not do,
> but please, do not violate the license of the code I contributed under
> GPLv2.


You mean "if you want to interact directly with arbitrary Linux kernel
functionality that we deem GPL-only, then you have to abide by its license"


Because the GPL-only symbol export makes it seem like most symbols are
NOT GPL-only. Why is there any distinction at all?


Why does the Linux kernel allow loading of non-GPL modules? Maybe it's
because the end user is ALLOWED to load non-GPL modules?


ZFS is ALLOWED to exist in the Linux ecosystem. It is not ALLOWED to be
distributed with the Linux kernel in binary form. The source trees can
not be merged without patent issues. No one is debating this.


What the issue here, is that previously a non-GPL module was working,
and now is not. NVIDIA is running GPL code?


>
> ZFS could be the best filesystem ever to grace this planet, that's
> fantastic, but given that the creators of that code placed it under a
> license that was specifically designed to not be compatible with Linux
> to prevent it from ever being used on Linux, well, you can see why I
> really don't care about it.  Why would I?


Asked last week for a source on this and you haven't provided any.
However, the SFLC plainly disagrees with you.


>
> Those copyright owners (well license owner at this point in time) could
> fix this all tomorrow if they wanted to.  But they do not, so _THEY_ are
> the people you should be upset at.  Not at the Linux kernel developers
> who are giving you a kernel on which to use on your systems, for free,
> under the GPLv2.  Our position has always been very clear and upfront.
> And really, so has the ZFS license creators.  So why is anyone upset
> about all of this?  Nothing new has changed here with the license of
> anything.


The previous situation was the STATUS QUO for years. Since 2012 we had
working ZFS on Linux with SIMD extensions, and now suddenly being told
that it is a license violation.


This is why people are upset at you, because you stand here waving a big
stick and telling us that we are breaking some rule you have merely
imagined.




>
> best of luck!
>
> greg k-h
>

Message received, loud and clear. We will go back to wrapping GPL-only
exports in our SPL (GPL licensed) kernel module. The Condom Works!


Best of luck with your windmills, Don Quixote.




Kash



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Stephan von Krawczynski]

On Tue, 15 Jan 2019 14:42:21 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> On Tue, Jan 15, 2019 at 02:01:48PM +0100, Rene Schickbauer wrote:
> > To be frank, your argument, which boils down to "GPL is the only correct
> > open source license", makes me ashamed to have been advocating people
> > switching to Linux. This is exactly the kind of argument that made me
> > switch away from closed source operating systems like Windows, only then
> > it was Steve Ballmer using it against open source.  
> 
> What?
> 
> No, my argument is, "If you want to interact directly with Linux kernel
> code in kernel-space, then you have to abide by it's license, which is
> GPLv2".  That's it.  If you wish to use open source code by another
> license, wonderful, I'm not telling you what you can, and can not do,
> but please, do not violate the license of the code I contributed under
> GPLv2.
> 
> ZFS could be the best filesystem ever to grace this planet, that's
> fantastic, but given that the creators of that code placed it under a
> license that was specifically designed to not be compatible with Linux
> to prevent it from ever being used on Linux, well, you can see why I
> really don't care about it.  Why would I?
> 
> Those copyright owners (well license owner at this point in time) could
> fix this all tomorrow if they wanted to.  But they do not, so _THEY_ are
> the people you should be upset at.  Not at the Linux kernel developers
> who are giving you a kernel on which to use on your systems, for free,
> under the GPLv2.  Our position has always been very clear and upfront.
> And really, so has the ZFS license creators.  So why is anyone upset
> about all of this?  Nothing new has changed here with the license of
> anything.
> 
> best of luck!
> 
> greg k-h

Hi Greg,

I'd say this is in fact more a moral question than a technical or legal issue.
The true background is the simple question what the project (i.e. linux) is in
fact all about, is it about helping people with lower skills or is it about
ruling people. A company (more or less every company) is more about ruling,
its aim is to move people into buying and using its products. Me (and quite
surely Rene at least) think that the linux _community_ is more about helping
others and hopefully less about legal and technical ruling.
So your argument "go to the company XYZ and blame them" isn't really
targetting in the right direction - as long as you see linux still as a
community thing and not as a cash-cow company-alike. Maybe it would be a lot
better to think about why there are people using ZFS and not some GPLed fs
instead. Me too being a ZFS user I can tell you the simple fact that there is
no GPL fs with equal features and stability (eh BTRFS). In fact quite some of
us would probably use HAMMER2 (thanks Matt) instead if sure that it equals ZFS
in terms of stability, still not BTRFS. So all you promote currently is the fs
deficit linux actually still has (and had for years, or say decades). I doubt
that this is/was helping the linux community a lot...
Sure maintainers have to rule sometimes, but it only makes sense if you are
able to present a working equal alternative. If you have none (and in this case
you have no alternative to offer) you will only push people away from the
community and that's probably not the right path for a community maintainer.
-- 
Only my 2ct,
Stephan

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Kash Pande]

[-- Attachment #1.1: Type: text/plain, Size: 1597 bytes --]


> Yes, the "GPL condom" attempt doesn't work at all.  It's been shot down
> a long time ago in the courts.

SFLC maintains there is no kernel licensing issue[1].

As a side note, even Hellwig's suit against VMware was dismissed (he may
appeal)[2].

Debian and Canonical base their decision to ship DKMS source for ZFS on
Linux[3].

The GPL does not disqualify a user from compiling ZFS or Linux however
they see fit.
It is only the users' distribution rights that come into question.

No one is combing ZFS into Linux or even distributing binary modules here;
we're following the terms of GPL.

> My tolerance for ZFS is pretty non-existant.  Sun explicitly did not
> want their code to work on Linux, so why would we do extra work to get
> their code to work properly?

1. Should your personal feelings affect the quality of the Linux kernel?
I say no.

2. Did Sun or Oracle ever release any statement of any kind that backs
your statement?

3. What extra work is being done here aside from the dropping of a
pseudo-protection,
the "GPL ONLY" symbol export? Something tells me, even if someone else
did "the work"
and submitted patches, you would find a reason to tell them to get
stuffed and leave
it "as-is".


With all of that... why have ANY kind of tolerance for out of tree
kernel modules at all?


[1] https://www.softwarefreedom.org/resources/2016/linux-kernel-cddl.html

[2] https://opensource.com/law/16/8/gpl-enforcement-action-hellwig-v-vmware

[3] https://lists.debian.org/debian-devel-announce/2015/04/msg00006.html









[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Kash Pande]

[-- Attachment #1.1: Type: text/plain, Size: 2311 bytes --]



> On Thu, Jan 10, 2019 at 07:07:52PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2019-01-10 17:32:58 [+0000], Hutter, Tony wrote:
> > > > But since when did out-of-tree modules use __kernel_fpu_begin? 
It's an
> > > > x86-only thing, and shouldn't really be used by anyone, right?
> > >
> > > ZFS on Linux uses it for checksums.  Its removal is currently
breaking ZFS builds against 5.0:
> >
> > So btrfs uses crc32c() / kernel's crypto API for that and ZFS can't?
> > Well the crypto API is GPL only exported so that won't work. crc32c() is
> > EXPORT_SYMBOL() so it would work.
> > On the other hand it does not look right to provide a EXPORT_SYMBOL
> > wrapper around a GPL only interface…

> Yes, the "GPL condom" attempt doesn't work at all.  It's been shot down
> a long time ago in the courts.

SFLC maintains there is no kernel licensing issue[1].

As a side note, even Hellwig's suit against VMware was dismissed (he may
appeal)[2].

Debian and Canonical base their decision to ship DKMS source for ZFS on
Linux[3].

The GPL does not disqualify a user from compiling ZFS or Linux however
they see fit.
It is only the users' distribution rights that come into question.

No one is combing ZFS into Linux or even distributing binary modules here;
we're following the terms of GPL.

> My tolerance for ZFS is pretty non-existant.  Sun explicitly did not
> want their code to work on Linux, so why would we do extra work to get
> their code to work properly?


1. Should your personal feelings affect the quality of the Linux kernel?
I say no.

2. Did Sun or Oracle ever release any statement of any kind that backs
your statement?

3. What extra work is being done here aside from the dropping of a
pseudo-protection,
the "GPL ONLY" symbol export? Something tells me, even if someone else
did "the work"
and submitted patches, you would find a reason to tell them to get
stuffed and leave
it "as-is".


With all of that... why have ANY kind of tolerance for out of tree
kernel modules at all?


[1] https://www.softwarefreedom.org/resources/2016/linux-kernel-cddl.html

[2] https://opensource.com/law/16/8/gpl-enforcement-action-hellwig-v-vmware

[3] https://lists.debian.org/debian-devel-announce/2015/04/msg00006.html




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

[Kash Pande]

[-- Attachment #1.1: Type: text/plain, Size: 236 bytes --]

On 2019-01-10 9:40 p.m., Greg Kroah-Hartman wrote:
> Sorry, no, we do not keep symbols exported for no in-kernel users.
>
> greg k-h


Hi Greg,


Can you please address the email that Lukas was responding to?


Thanks.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]