From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753372AbcCLPMX (ORCPT ); Sat, 12 Mar 2016 10:12:23 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:36024 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752587AbcCLPMO (ORCPT ); Sat, 12 Mar 2016 10:12:14 -0500 Date: Sat, 12 Mar 2016 16:12:10 +0100 From: Ingo Molnar To: Linus Torvalds Cc: Borislav Petkov , "Bryan O'Donoghue" , Andy Lutomirski , Andy Shevchenko , "linux-kernel@vger.kernel.org" , "x86@kernel.org" , Fenghua Yu , "H. Peter Anvin" , Thomas Gleixner , Andrew Morton , Dave Hansen , Oleg Nesterov , "Yu, Yu-cheng" Subject: Re: [PATCH] x86/FPU: Fix FPU handling on legacy FPU machines Message-ID: <20160312151209.GA9356@gmail.com> References: <20160310145940.GB26708@pd.tnic> <20160311090840.GA8486@gmail.com> <20160311094802.GA4312@pd.tnic> <1457694124.2007.12.camel@nexus-software.ie> <20160311112610.GC4312@pd.tnic> <20160311113206.GD4312@pd.tnic> <20160312150809.GA7015@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160312150809.GA7015@gmail.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 * Ingo Molnar wrote: > * Linus Torvalds wrote: > > > On Fri, Mar 11, 2016 at 3:32 AM, Borislav Petkov wrote: > > > 486 cores like Intel Quark support only the very old, legacy x87 FPU > > > (FSAVE/FRSTOR, CPUID bit FXSR is not set). And our FPU code wasn't > > > handling the saving and restoring there properly. First, Andy Shevchenko > > > reported a splat: > > > > > > WARNING: CPU: 0 PID: 823 at arch/x86/include/asm/fpu/internal.h:163 fpu__clear+0x8c/0x160 > > > > > > which was us trying to execute FXRSTOR on those machines even though > > > they don't support it. > > > > > > After taking care of that, Bryan O'Donoghue reported that a simple FPU > > > test still failed because we weren't initializing the FPU state properly > > > on those machines. > > > > Obvious Ack to the patch, along with a "how did this ever work > > before?" comment.. > > So the window for 'real' breakage was relatively short: this is an older bug but > only became a serious bug with the following upcoming commit: > > 58122bf1d856 x86/fpu: Default eagerfpu=on on all CPUs And the reason for that is: void fpu__clear(struct fpu *fpu) { WARN_ON_FPU(fpu != ¤t->thread.fpu); /* Almost certainly an anomaly */ if (!use_eager_fpu() || !static_cpu_has(X86_FEATURE_FPU)) { /* FPU state will be reallocated lazily at the first use. */ fpu__drop(fpu); } else { if (!fpu->fpstate_active) { fpu__activate_curr(fpu); user_fpu_begin(); } copy_init_fpstate_to_fpregs(); } } i.e. we only execute the buggy sequence in the !eager_fpu case - and old FPUs were not eager-FPU, which hid the bug. The other bug: @@ -134,7 +134,7 @@ static void __init fpu__init_system_gene * Set up the legacy init FPU context. (xstate init might overwrite this * with a more modern format, if the CPU supports it.) */ - fpstate_init_fxstate(&init_fpstate.fxsave); + fpstate_init(&init_fpstate); was also hidden by the fact that it only affects eagerfpu case - but all previous eagerfpu bootups were for post-XSAVE CPUs. Thanks, Ingo