lkml.org 
[lkml]   [2015]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.



\
 
 \ /
  Last update: 2015-03-15 19:41    [W:0.159 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site