Messages in this thread | | | Date | Sun, 15 Mar 2015 19:16:43 +0100 | From | Oleg Nesterov <> | Subject | Re: [PATCH 4/4] x86/fpu: don't abuse drop_init_fpu() in flush_thread() |
| |
On 03/15, Borislav Petkov wrote: > > On Sat, Mar 14, 2015 at 03:48:16PM +0100, Oleg Nesterov wrote: > > > > > > > > __kernel_fpu_end() needs to restore FPU from current's fpu->state exactly > > > > because current used FPU prior. And that state was saved by __save_init_fpu() > > > > in __kernel_fpu_begin(). > > > > > > That's exactly what I mean. See: "... kernel is done with FPU and current was > > > using the FPU prior..." > > > > Yes, but my point was that this is why we can _not_ use drop_init_fpu() in > > __kernel_fpu_end(). > > Hmm, now I'm confused.
Me too...
> void __kernel_fpu_end(): > > ... > > if (__thread_has_fpu(me)) { > if (WARN_ON(restore_fpu_checking(me))) > > restore_fpu_checking(current) does try to restore fpu->state and it does > drop_init_fpu() only if it failed. > > Ok, now you tell me what I'm missing :)
Of course, drop_init_fpu() is fine if restore_fpu_checking() fails.
Did you mean this from the very beginning? In this case I agree of course.
Because I misinterpreted your initial comment:
One example where drop_init_fpu() seems to make sense is __kernel_fpu_end(): kernel is done with FPU and current was using the FPU prior so let's restore it for the eagerfpu case.
as if you suggest to use it _instead_ of restore_fpu_checking().
Oleg.
| |