[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150113175804.GA29851@redhat.com>
Date: Tue, 13 Jan 2015 18:58:04 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: riel@...hat.com
Cc: linux-kernel@...r.kernel.org, mingo@...hat.com, hpa@...or.com,
matt.fleming@...el.com, bp@...e.de, pbonzini@...hat.com,
tglx@...utronix.de, luto@...capital.net
Subject: Re: [RFC PATCH 04/11] x86,fpu: defer FPU restore until return to
userspace
On 01/11, riel@...hat.com wrote:
>
> Defer restoring the FPU state, if so desired, until the task returns to
> userspace.
And yet another concern ;) Although I feel that I am totally confused and
probably wrong.
> --- a/arch/x86/include/asm/fpu-internal.h
> +++ b/arch/x86/include/asm/fpu-internal.h
> @@ -382,6 +382,7 @@ static inline void drop_init_fpu(struct task_struct *tsk)
> else
> fxrstor_checking(&init_xstate_buf->i387);
> }
> + clear_thread_flag(TIF_LOAD_FPU);
> }
OK, but shouldn't (say) restore_user_xstate() clear TIF_LOAD_FPU too?
Otherwise, can't switch_fpu_finish() restore the wrong context later?
Or. Perhaps switch_fpu_finish() should do nothing if fpu.has_fpu == T,
I dunno.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists