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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

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