> > > > This is a note to let you know that I've just added the patch titled
> > > >
> > > > x86/fpu: Don't export __kernel_fpu_{begin,end}()
> > > >
> > > > to the 4.19-stable tree which can be found at:
> > > >
On Thu, May 2, 2019 at 1:02 AM Greg KH wrote:
>
> On Wed, May 01, 2019 at 10:47:07AM -0700, Andy Lutomirski wrote:
> > On Mon, Apr 29, 2019 at 6:36 AM wrote:
> > >
> > >
> > > This is a note to let you know that I've just added the patch titled
> > &g
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
On Tue, 15 Jan 2019 14:42:21 +0100
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
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
> 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
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
Hi Rene,
please switch to FreeBSD instead of advocating to violate the copyright
and licensing rule on my and others work.
Thanks you!
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
[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
> > >
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.
signature.asc
Description: OpenPGP digital signature
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
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
> 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
> On Thu, Jan 10, 2019 at 07:07:52PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2019-01-10 17:32:58 [+], 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?
> > >
> > >
On Thu, Jan 10, 2019 at 07:07:52PM +0100, Sebastian Andrzej Siewior wrote:
> On 2019-01-10 17:32:58 [+], 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
On 2019-01-10 17:32:58 [+], 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:
> 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:
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
> 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
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
>
On Wed, Jan 9, 2019 at 1:09 PM 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
>
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
5b8be205
> > > 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
On 2019-01-07 18:08:26 [-0400], Marc Dionne wrote:
> On Thu, Dec 27, 2018 at 11:20 AM Linux Kernel Mailing List
> wrote:
> >
> > Commit: 12209993e98c5fa1855c467f22a24e3d5b8be205
> > x86/fpu: Don't export __kernel_fpu_{begin,end}()
> >
…
> >
nel.org/torvalds/c/12209993e98c5fa1855c467f22a24e3d5b8be205
> Author: Sebastian Andrzej Siewior
> AuthorDate: Thu Nov 29 16:02:10 2018 +0100
> Committer: Borislav Petkov
> CommitDate: Tue Dec 4 12:37:28 2018 +0100
>
> x86/fpu: Don't export __kernel_fpu_{begin,end}()
>
> There is one user o
There is one user using __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
There is one user using __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
On Wed, 2018-11-28 at 23:20 +0100, Sebastian Andrzej Siewior wrote:
>
> + * Use kernel_fpu_begin/end() if you intend to use FPU in kernel
> context. It
> + * disables preemption so be carefull if you intend to use it for
> long periods
Just how careful do you want to be?
One l seems sufficient
On Wed, 2018-11-28 at 23:20 +0100, Sebastian Andrzej Siewior wrote:
>
> + * Use kernel_fpu_begin/end() if you intend to use FPU in kernel
> context. It
> + * disables preemption so be carefull if you intend to use it for
> long periods
Just how careful do you want to be?
One l seems sufficient
There is one user using __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
There is one user using __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
31 matches
Mail list logo
