On 03/13, Borislav Petkov wrote: > > On Wed, Mar 11, 2015 at 06:34:49PM +0100, Oleg Nesterov wrote: > > Change flush_thread() to do user_fpu_begin() + restore_init_xstate() > > and avoid math_state_restore(). > > > > Note: "TODO: cleanup this horror" is still valid. We do not need > > init_fpu() at all, we only need fpu_alloc() + memset(0). But this needs > > other changes, in particular user_fpu_begin() should set used_math(). > > > > Signed-off-by: Oleg Nesterov <[email protected]> > > --- > > arch/x86/kernel/process.c | 3 ++- > > 1 files changed, 2 insertions(+), 1 deletions(-) > > > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > > index dd9a069..c396de2 100644 > > --- a/arch/x86/kernel/process.c > > +++ b/arch/x86/kernel/process.c > > @@ -142,7 +142,8 @@ void flush_thread(void) > > /* kthread execs. TODO: cleanup this horror. */ > > if (WARN_ON(init_fpu(current))) > > force_sig(SIGKILL, current); > > - math_state_restore(); > > + user_fpu_begin(); > > + restore_init_xstate(); > > Ok, question: so math_state_restore() does kernel_fpu_disable() before > doing those, why is it ok for flush_thread() to not do it?
You mean, why restore_init_xstate() is safe? Because in math_state_restore() case kernel_fpu_begin()->__save_init_fpu() will overwrite (corrupt) the same fpu->state buffer we need to restore. Without kernel_fpu_disable(). restore_init_xstate() obviously differs because it reads init_xstate_buf, we do not care at all if kernel_fpu_begin() in between overwrites ->state. And note! this is the yet another proof that init_fpu()->fpu_finit() is pointless. This (and almost all) users need fpu_alloc() only. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
