Re: Patch "x86/fpu: Don't export __kernel_fpu_{begin,end}()" has been added to the 4.19-stable tree
On Thu, May 02, 2019 at 07:42:21AM -0700, Andy Lutomirski wrote: > 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 > > > > > > > > x86/fpu: Don't export __kernel_fpu_{begin,end}() > > > > > > > > to the 4.19-stable tree which can be found at: > > > > > > > > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary > > > > > > Why? ISTM the only possible effect is to break out-of-tree modules. > > > I have no objection to breaking such modules if we need to, but, in > > > this case, I don't see the benefit. > > > > The "benefit" is that people keep complaining that newer kernels do not > > have this api for some reason and that it is a "regression", which > > completely does not understand how the kernel handles internal apis. > > I suppose that's a reasonable point. But maybe we should actually > give these modules a credible alternative first? I just send a patch. That's your call, it's your code :) thanks, greg k-h
Re: Patch "x86/fpu: Don't export __kernel_fpu_{begin,end}()" has been added to the 4.19-stable tree
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 > > > > > > x86/fpu: Don't export __kernel_fpu_{begin,end}() > > > > > > to the 4.19-stable tree which can be found at: > > > > > > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary > > > > Why? ISTM the only possible effect is to break out-of-tree modules. > > I have no objection to breaking such modules if we need to, but, in > > this case, I don't see the benefit. > > The "benefit" is that people keep complaining that newer kernels do not > have this api for some reason and that it is a "regression", which > completely does not understand how the kernel handles internal apis. I suppose that's a reasonable point. But maybe we should actually give these modules a credible alternative first? I just send a patch.
Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()
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 signature.asc Description: Digital signature
Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()
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 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}()
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 signature.asc Description: OpenPGP digital signature
Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()
> 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/msg6.html signature.asc Description: OpenPGP digital signature
Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()
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}()
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}()
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}()
[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}()
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
Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()
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}()
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}()
> 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/msg6.html signature.asc Description: OpenPGP digital signature
Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()
> 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 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/msg6.html signature.asc Description: OpenPGP digital signature
Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()
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 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}()
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: 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}()
> 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}()
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 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}()
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}()
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 > 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}()
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}()
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 > > 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}()
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}() > > … > > 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}()
On Thu, Dec 27, 2018 at 11:20 AM Linux Kernel Mailing List wrote: > > Commit: 12209993e98c5fa1855c467f22a24e3d5b8be205 > Parent: 2f2fcc40a961ed04f0e130803fbaa868c2899310 > Refname:refs/heads/master > Web: > https://git.kernel.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 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 > Signed-off-by: Borislav Petkov > Reviewed-by: Rik van Riel > Cc: "H. Peter Anvin" > Cc: "Jason A. Donenfeld" > Cc: Andy Lutomirski > Cc: Ard Biesheuvel > Cc: Dave Hansen > Cc: Ingo Molnar > Cc: Nicolai Stange > Cc: Paolo Bonzini > Cc: Radim Krčmář > Cc: Thomas Gleixner > Cc: kvm ML > Cc: linux-efi > Cc: x86-ml > Link: > https://lkml.kernel.org/r/20181129150210.2k4mawt37ow6c...@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
[PATCH 07/29 v2] x86/fpu: don't export __kernel_fpu_{begin|end}()
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 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}(), it can be made static and not exported anymore. Reviewed-by: Rik van Riel Signed-off-by: Sebastian Andrzej Siewior --- v1…v2: `carefull' -> `careful' arch/x86/include/asm/efi.h | 6 ++ arch/x86/include/asm/fpu/api.h | 16 ++-- arch/x86/kernel/fpu/core.c | 6 ++ 3 files changed, 10 insertions(+), 18 deletions(-) diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h index eea40d52ca785..45864898f7e50 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 a9caac9d4a729..e368d8d94ca68 100644 --- a/arch/x86/include/asm/fpu/api.h +++ b/arch/x86/include/asm/fpu/api.h @@ -12,17 +12,13 @@ #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. + * Using the FPU in hardirq is not allowed. */ -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 2ea85b32421a0..2e5003fef51a9 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 = >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 = >thread.fpu; @@ -122,7 +121,6 @@ void __kernel_fpu_end(void) kernel_fpu_enable(); } -EXPORT_SYMBOL(__kernel_fpu_end); void kernel_fpu_begin(void) { -- 2.20.0.rc1
[PATCH 07/29 v2] x86/fpu: don't export __kernel_fpu_{begin|end}()
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 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}(), it can be made static and not exported anymore. Reviewed-by: Rik van Riel Signed-off-by: Sebastian Andrzej Siewior --- v1…v2: `carefull' -> `careful' arch/x86/include/asm/efi.h | 6 ++ arch/x86/include/asm/fpu/api.h | 16 ++-- arch/x86/kernel/fpu/core.c | 6 ++ 3 files changed, 10 insertions(+), 18 deletions(-) diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h index eea40d52ca785..45864898f7e50 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 a9caac9d4a729..e368d8d94ca68 100644 --- a/arch/x86/include/asm/fpu/api.h +++ b/arch/x86/include/asm/fpu/api.h @@ -12,17 +12,13 @@ #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. + * Using the FPU in hardirq is not allowed. */ -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 2ea85b32421a0..2e5003fef51a9 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 = >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 = >thread.fpu; @@ -122,7 +121,6 @@ void __kernel_fpu_end(void) kernel_fpu_enable(); } -EXPORT_SYMBOL(__kernel_fpu_end); void kernel_fpu_begin(void) { -- 2.20.0.rc1
Re: [PATCH 07/29] x86/fpu: don't export __kernel_fpu_{begin|end}()
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 :) Feel free to add my Reviewed-by: once that spelling error is fixed :) -- All Rights Reversed. signature.asc Description: This is a digitally signed message part
Re: [PATCH 07/29] x86/fpu: don't export __kernel_fpu_{begin|end}()
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 :) Feel free to add my Reviewed-by: once that spelling error is fixed :) -- All Rights Reversed. signature.asc Description: This is a digitally signed message part
[PATCH 07/29] x86/fpu: don't export __kernel_fpu_{begin|end}()
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 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}(), it can be made static and not exported anymore. Signed-off-by: Sebastian Andrzej Siewior --- arch/x86/include/asm/efi.h | 6 ++ arch/x86/include/asm/fpu/api.h | 16 ++-- arch/x86/kernel/fpu/core.c | 6 ++ 3 files changed, 10 insertions(+), 18 deletions(-) diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h index eea40d52ca785..45864898f7e50 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 a9caac9d4a729..d6e094c282779 100644 --- a/arch/x86/include/asm/fpu/api.h +++ b/arch/x86/include/asm/fpu/api.h @@ -12,17 +12,13 @@ #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 carefull 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. + * Using the FPU in hardirq is not allowed. */ -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 2ea85b32421a0..2e5003fef51a9 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 = >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 = >thread.fpu; @@ -122,7 +121,6 @@ void __kernel_fpu_end(void) kernel_fpu_enable(); } -EXPORT_SYMBOL(__kernel_fpu_end); void kernel_fpu_begin(void) { -- 2.20.0.rc1
[PATCH 07/29] x86/fpu: don't export __kernel_fpu_{begin|end}()
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 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}(), it can be made static and not exported anymore. Signed-off-by: Sebastian Andrzej Siewior --- arch/x86/include/asm/efi.h | 6 ++ arch/x86/include/asm/fpu/api.h | 16 ++-- arch/x86/kernel/fpu/core.c | 6 ++ 3 files changed, 10 insertions(+), 18 deletions(-) diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h index eea40d52ca785..45864898f7e50 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 a9caac9d4a729..d6e094c282779 100644 --- a/arch/x86/include/asm/fpu/api.h +++ b/arch/x86/include/asm/fpu/api.h @@ -12,17 +12,13 @@ #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 carefull 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. + * Using the FPU in hardirq is not allowed. */ -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 2ea85b32421a0..2e5003fef51a9 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 = >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 = >thread.fpu; @@ -122,7 +121,6 @@ void __kernel_fpu_end(void) kernel_fpu_enable(); } -EXPORT_SYMBOL(__kernel_fpu_end); void kernel_fpu_begin(void) { -- 2.20.0.rc1