Re: [PATCH 4/4] x86/fpu: don't abuse drop_init_fpu() in flush_thread()

[Oleg Nesterov]

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/