lkml.org 
[lkml]   [2015]   [Mar]   [13]   [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/13, Borislav Petkov wrote:
    >
    > On Fri, Mar 13, 2015 at 03:55:42PM +0100, Oleg Nesterov wrote:
    > > But please look at drop_init_fpu(). If eagerfpu == F it calls drop_fpu() and
    > > this is what we need. flush_thread() already has the "if (!use_eager_fpu())",
    > > we can shift drop_fpu() there.
    > >
    > > Otherwise, if eagerfpu == T, drop_init_fpu() does restore_init_xstate() and
    > > this just burns CPU. Until flush_thread user_has_fpu/used_math this state
    > > restore_init_xstate() is pointless, this state will be lost after preemption.
    >
    > Yeah, I was wondering why that's there.
    >
    > 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.

    No, no, this is another case or I misunderstood you.

    __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().

    Oleg.



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