Re: [PATCH 11/29] x86/fpu: Always init the `state' in fpu__clear()

[Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>]

On 2018-12-12 18:11:29 [+0100], Borislav Petkov wrote:
> > diff --git a/arch/x86/math-emu/fpu_entry.c b/arch/x86/math-emu/fpu_entry.c
> > index 9e2ba7e667f61..a873da6b46d6b 100644
> > --- a/arch/x86/math-emu/fpu_entry.c
> > +++ b/arch/x86/math-emu/fpu_entry.c
> > @@ -113,9 +113,6 @@ void math_emulate(struct math_emu_info *info)
> >  	unsigned long code_base = 0;
> >  	unsigned long code_limit = 0;	/* Initialized to stop compiler warnings */
> >  	struct desc_struct code_descriptor;
> > -	struct fpu *fpu = &current->thread.fpu;
> > -
> > -	fpu__initialize(fpu);
> 
> Ok, you're removing it here but where is the FPU going to be initialized
> now in the FPU-less case?
> 
> IOW, it is not clear to me where fpu__clear() get called for the FPU
> emulation case now...

During fork() fpu__initialize() is called for both (with and without
FPU) systems. The difference is made in fpu__clear() where the init is
avoided in the FPU-less case. With this hunk:

--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -365,8 +364,8 @@ void fpu__clear(struct fpu *fpu)
        /*
         * Make sure fpstate is cleared and initialized.
         */
+       fpu__initialize(fpu);
        if (static_cpu_has(X86_FEATURE_FPU)) {
-               fpu__initialize(fpu);
                user_fpu_begin();
                copy_init_fpstate_to_fpregs();
        }                                                                                                                                                                                 
we have the initialization in both cases.
The only "negative" thing might be that we now have a memset(, 0, 684)
(fpstate_init_soft()) during fork which would be avoided in case the
FPU-less system has a userland which is compiled with a soft-FPU toolchain.

I would worry about it once someone complains (and I doubt someone
complains even if we remove soft FPU support).

Sebastian