* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() [not found] <git-mailbomb-linux-master-12209993e98c5fa1855c467f22a24e3d5b8be205@kernel.org> @ 2019-01-07 22:08 ` Marc Dionne 2019-01-09 11:19 ` Sebastian Andrzej Siewior 0 siblings, 1 reply; 23+ messages in thread From: Marc Dionne @ 2019-01-07 22:08 UTC (permalink / raw) To: Sebastian Andrzej Siewior; +Cc: Linux Kernel Mailing List 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 = ¤t->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 = ¤t->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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() 2019-01-07 22:08 ` x86/fpu: Don't export __kernel_fpu_{begin,end}() Marc Dionne @ 2019-01-09 11:19 ` Sebastian Andrzej Siewior 2019-01-09 16:52 ` Greg Kroah-Hartman 0 siblings, 1 reply; 23+ messages in thread From: Sebastian Andrzej Siewior @ 2019-01-09 11:19 UTC (permalink / raw) To: Marc Dionne, Greg Kroah-Hartman, Linus Torvalds Cc: Linux Kernel Mailing List, x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() 2019-01-09 11:19 ` Sebastian Andrzej Siewior @ 2019-01-09 16:52 ` Greg Kroah-Hartman 2019-01-09 17:09 ` Sebastian Andrzej Siewior 0 siblings, 1 reply; 23+ messages in thread From: Greg Kroah-Hartman @ 2019-01-09 16:52 UTC (permalink / raw) To: Sebastian Andrzej Siewior Cc: Marc Dionne, Linus Torvalds, Linux Kernel Mailing List, x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() 2019-01-09 16:52 ` Greg Kroah-Hartman @ 2019-01-09 17:09 ` Sebastian Andrzej Siewior 2019-01-09 17:40 ` Marc Dionne 2019-01-10 13:11 ` Greg Kroah-Hartman 0 siblings, 2 replies; 23+ messages in thread From: Sebastian Andrzej Siewior @ 2019-01-09 17:09 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Marc Dionne, Linus Torvalds, Linux Kernel Mailing List, x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() 2019-01-09 17:09 ` Sebastian Andrzej Siewior @ 2019-01-09 17:40 ` Marc Dionne 2019-01-10 13:13 ` Greg Kroah-Hartman 2019-01-10 13:11 ` Greg Kroah-Hartman 1 sibling, 1 reply; 23+ messages in thread From: Marc Dionne @ 2019-01-09 17:40 UTC (permalink / raw) To: Sebastian Andrzej Siewior Cc: Greg Kroah-Hartman, Linus Torvalds, Linux Kernel Mailing List, x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() 2019-01-09 17:40 ` Marc Dionne @ 2019-01-10 13:13 ` Greg Kroah-Hartman 0 siblings, 0 replies; 23+ messages in thread From: Greg Kroah-Hartman @ 2019-01-10 13:13 UTC (permalink / raw) To: Marc Dionne Cc: Sebastian Andrzej Siewior, Linus Torvalds, Linux Kernel Mailing List, x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() 2019-01-09 17:09 ` Sebastian Andrzej Siewior 2019-01-09 17:40 ` Marc Dionne @ 2019-01-10 13:11 ` Greg Kroah-Hartman 2019-01-10 17:32 ` Hutter, Tony 1 sibling, 1 reply; 23+ messages in thread From: Greg Kroah-Hartman @ 2019-01-10 13:11 UTC (permalink / raw) To: Sebastian Andrzej Siewior Cc: Marc Dionne, Linus Torvalds, Linux Kernel Mailing List, x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() 2019-01-10 13:11 ` Greg Kroah-Hartman @ 2019-01-10 17:32 ` Hutter, Tony 2019-01-10 18:07 ` Sebastian Andrzej Siewior 0 siblings, 1 reply; 23+ messages in thread From: Hutter, Tony @ 2019-01-10 17:32 UTC (permalink / raw) To: Greg Kroah-Hartman, Sebastian Andrzej Siewior Cc: Marc Dionne, Linus Torvalds, Linux Kernel Mailing List, x86 > 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() 2019-01-10 17:32 ` Hutter, Tony @ 2019-01-10 18:07 ` Sebastian Andrzej Siewior 2019-01-10 18:24 ` Greg Kroah-Hartman 0 siblings, 1 reply; 23+ messages in thread From: Sebastian Andrzej Siewior @ 2019-01-10 18:07 UTC (permalink / raw) To: Hutter, Tony Cc: Greg Kroah-Hartman, Marc Dionne, Linus Torvalds, Linux Kernel Mailing List, x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() 2019-01-10 18:07 ` Sebastian Andrzej Siewior @ 2019-01-10 18:24 ` Greg Kroah-Hartman 2019-01-11 3:18 ` Kash Pande ` (3 more replies) 0 siblings, 4 replies; 23+ messages in thread From: Greg Kroah-Hartman @ 2019-01-10 18:24 UTC (permalink / raw) To: Sebastian Andrzej Siewior Cc: Hutter, Tony, Marc Dionne, Linus Torvalds, Linux Kernel Mailing List, x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() 2019-01-10 18:24 ` Greg Kroah-Hartman @ 2019-01-11 3:18 ` Kash Pande 2019-01-11 5:04 ` Lukas Wunner ` (2 subsequent siblings) 3 siblings, 0 replies; 23+ messages in thread From: Kash Pande @ 2019-01-11 3:18 UTC (permalink / raw) To: linux-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() 2019-01-10 18:24 ` Greg Kroah-Hartman 2019-01-11 3:18 ` Kash Pande @ 2019-01-11 5:04 ` Lukas Wunner 2019-01-11 5:40 ` Greg Kroah-Hartman 2019-01-15 13:01 ` Rene Schickbauer 2019-01-15 18:26 ` Kash Pande 3 siblings, 1 reply; 23+ messages in thread From: Lukas Wunner @ 2019-01-11 5:04 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Sebastian Andrzej Siewior, Hutter, Tony, Marc Dionne, Linus Torvalds, Linux Kernel Mailing List, x86, Kash Pande 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() 2019-01-11 5:04 ` Lukas Wunner @ 2019-01-11 5:40 ` Greg Kroah-Hartman 2019-01-11 18:06 ` Lukas Wunner 2019-01-23 15:58 ` Pavel Machek 0 siblings, 2 replies; 23+ messages in thread From: Greg Kroah-Hartman @ 2019-01-11 5:40 UTC (permalink / raw) To: Lukas Wunner Cc: Sebastian Andrzej Siewior, Hutter, Tony, Marc Dionne, Linus Torvalds, Linux Kernel Mailing List, x86, Kash Pande 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() 2019-01-11 5:40 ` Greg Kroah-Hartman @ 2019-01-11 18:06 ` Lukas Wunner 2019-01-23 15:58 ` Pavel Machek 1 sibling, 0 replies; 23+ messages in thread From: Lukas Wunner @ 2019-01-11 18:06 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Sebastian Andrzej Siewior, Hutter, Tony, Marc Dionne, Linus Torvalds, Linux Kernel Mailing List, x86, Kash Pande, Ingo Molnar [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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() 2019-01-11 5:40 ` Greg Kroah-Hartman 2019-01-11 18:06 ` Lukas Wunner @ 2019-01-23 15:58 ` Pavel Machek 1 sibling, 0 replies; 23+ messages in thread From: Pavel Machek @ 2019-01-23 15:58 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Lukas Wunner, Sebastian Andrzej Siewior, Hutter, Tony, Marc Dionne, Linus Torvalds, Linux Kernel Mailing List, x86, Kash Pande [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() 2019-01-10 18:24 ` Greg Kroah-Hartman 2019-01-11 3:18 ` Kash Pande 2019-01-11 5:04 ` Lukas Wunner @ 2019-01-15 13:01 ` Rene Schickbauer 2019-01-15 13:32 ` Christoph Hellwig 2019-01-15 13:42 ` Greg Kroah-Hartman 2019-01-15 18:26 ` Kash Pande 3 siblings, 2 replies; 23+ messages in thread From: Rene Schickbauer @ 2019-01-15 13:01 UTC (permalink / raw) To: Greg Kroah-Hartman, Sebastian Andrzej Siewior Cc: Hutter, Tony, Marc Dionne, Linus Torvalds, Linux Kernel Mailing List, x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() 2019-01-15 13:01 ` Rene Schickbauer @ 2019-01-15 13:32 ` Christoph Hellwig 2019-01-15 13:42 ` Greg Kroah-Hartman 1 sibling, 0 replies; 23+ messages in thread From: Christoph Hellwig @ 2019-01-15 13:32 UTC (permalink / raw) To: Rene Schickbauer Cc: Greg Kroah-Hartman, Sebastian Andrzej Siewior, Hutter, Tony, Marc Dionne, Linus Torvalds, Linux Kernel Mailing List, x86 Hi Rene, please switch to FreeBSD instead of advocating to violate the copyright and licensing rule on my and others work. Thanks you! ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() 2019-01-15 13:01 ` Rene Schickbauer 2019-01-15 13:32 ` Christoph Hellwig @ 2019-01-15 13:42 ` Greg Kroah-Hartman 2019-01-15 18:51 ` Kash Pande 2019-01-21 12:30 ` Stephan von Krawczynski 1 sibling, 2 replies; 23+ messages in thread From: Greg Kroah-Hartman @ 2019-01-15 13:42 UTC (permalink / raw) To: Rene Schickbauer Cc: Sebastian Andrzej Siewior, Hutter, Tony, Marc Dionne, Linus Torvalds, Linux Kernel Mailing List, x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() 2019-01-15 13:42 ` Greg Kroah-Hartman @ 2019-01-15 18:51 ` Kash Pande 2019-01-21 12:30 ` Stephan von Krawczynski 1 sibling, 0 replies; 23+ messages in thread From: Kash Pande @ 2019-01-15 18:51 UTC (permalink / raw) To: linux-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() 2019-01-15 13:42 ` Greg Kroah-Hartman 2019-01-15 18:51 ` Kash Pande @ 2019-01-21 12:30 ` Stephan von Krawczynski 1 sibling, 0 replies; 23+ messages in thread From: Stephan von Krawczynski @ 2019-01-21 12:30 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Rene Schickbauer, Sebastian Andrzej Siewior, Hutter, Tony, Marc Dionne, Linus Torvalds, Linux Kernel Mailing List, x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() 2019-01-10 18:24 ` Greg Kroah-Hartman ` (2 preceding siblings ...) 2019-01-15 13:01 ` Rene Schickbauer @ 2019-01-15 18:26 ` Kash Pande 3 siblings, 0 replies; 23+ messages in thread From: Kash Pande @ 2019-01-15 18:26 UTC (permalink / raw) To: linux-kernel; +Cc: Greg Kroah-Hartman [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() @ 2019-01-11 3:07 Kash Pande 0 siblings, 0 replies; 23+ messages in thread From: Kash Pande @ 2019-01-11 3:07 UTC (permalink / raw) To: linux-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <20190111054058.GA27966 () kroah ! com>]
* Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() [not found] <20190111054058.GA27966 () kroah ! com> @ 2019-01-11 6:24 ` Kash Pande 0 siblings, 0 replies; 23+ messages in thread From: Kash Pande @ 2019-01-11 6:24 UTC (permalink / raw) To: Greg Kroah-Hartman, linux-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2019-01-23 15:58 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <git-mailbomb-linux-master-12209993e98c5fa1855c467f22a24e3d5b8be205@kernel.org> 2019-01-07 22:08 ` x86/fpu: Don't export __kernel_fpu_{begin,end}() Marc Dionne 2019-01-09 11:19 ` Sebastian Andrzej Siewior 2019-01-09 16:52 ` Greg Kroah-Hartman 2019-01-09 17:09 ` Sebastian Andrzej Siewior 2019-01-09 17:40 ` Marc Dionne 2019-01-10 13:13 ` Greg Kroah-Hartman 2019-01-10 13:11 ` Greg Kroah-Hartman 2019-01-10 17:32 ` Hutter, Tony 2019-01-10 18:07 ` Sebastian Andrzej Siewior 2019-01-10 18:24 ` Greg Kroah-Hartman 2019-01-11 3:18 ` Kash Pande 2019-01-11 5:04 ` Lukas Wunner 2019-01-11 5:40 ` Greg Kroah-Hartman 2019-01-11 18:06 ` Lukas Wunner 2019-01-23 15:58 ` Pavel Machek 2019-01-15 13:01 ` Rene Schickbauer 2019-01-15 13:32 ` Christoph Hellwig 2019-01-15 13:42 ` Greg Kroah-Hartman 2019-01-15 18:51 ` Kash Pande 2019-01-21 12:30 ` Stephan von Krawczynski 2019-01-15 18:26 ` Kash Pande 2019-01-11 3:07 Kash Pande [not found] <20190111054058.GA27966 () kroah ! com> 2019-01-11 6:24 ` Kash Pande
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).