From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752774AbbCORhx (ORCPT ); Sun, 15 Mar 2015 13:37:53 -0400 Received: from cantor2.suse.de ([195.135.220.15]:55369 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751106AbbCORhw (ORCPT ); Sun, 15 Mar 2015 13:37:52 -0400 Date: Sun, 15 Mar 2015 18:36:20 +0100 From: Borislav Petkov To: Oleg Nesterov Cc: Dave Hansen , Ingo Molnar , Andy Lutomirski , Linus Torvalds , Pekka Riikonen , Rik van Riel , Suresh Siddha , LKML , "Yu, Fenghua" , Quentin Casasnovas Subject: Re: [PATCH 4/4] x86/fpu: don't abuse drop_init_fpu() in flush_thread() Message-ID: <20150315173620.GA29134@pd.tnic> References: <54F74F59.5070107@intel.com> <20150311173346.GB5032@redhat.com> <20150311173507.GF5032@redhat.com> <20150313105251.GD31998@pd.tnic> <20150313145542.GD21603@redhat.com> <20150313161958.GI31998@pd.tnic> <20150313162654.GA26453@redhat.com> <20150313192717.GJ31998@pd.tnic> <20150314144816.GA13029@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150314144816.GA13029@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Mar 14, 2015 at 03:48:16PM +0100, Oleg Nesterov wrote: > On 03/13, Borislav Petkov wrote: > > On Fri, Mar 13, 2015 at 05:26:54PM +0100, Oleg Nesterov wrote: > > > > 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(). > > > > 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. So __kernel_fpu_end() says kernel finished using the FPU and we need to do the following: * current has the FPU => let's restore it. If there was an error doing that, we do drop_init, i.e. restore init_xstate in the eager case and otherwise we just drop it. So that makes perfect sense to me. * otherwise, current didn't have the FPU, we simply set CR0.TS in the non-eager case so that we can fault on the next use of an FPU insn. To address your comment from earlier: > > > __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(). And we do that: 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 :) Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --