From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754512AbbK0KGe (ORCPT ); Fri, 27 Nov 2015 05:06:34 -0500 Received: from mail-wm0-f42.google.com ([74.125.82.42]:34906 "EHLO mail-wm0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753965AbbK0KGb (ORCPT ); Fri, 27 Nov 2015 05:06:31 -0500 Date: Fri, 27 Nov 2015 11:06:27 +0100 From: Ingo Molnar To: Dave Hansen Cc: linux-kernel@vger.kernel.org, dave.hansen@linux.intel.com, x86@kernel.org, luto@kernel.org, fenghua.yu@intel.com, yu-cheng.yu@intel.com Subject: Re: [PATCH] x86, fpu: fix 32-bit signal frame handling Message-ID: <20151127100627.GA32475@gmail.com> References: <20151111002354.A0799571@viggo.jf.intel.com> <564517CA.7090600@sr71.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <564517CA.7090600@sr71.net> 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 * Dave Hansen wrote: > On 11/10/2015 04:23 PM, Dave Hansen wrote: > > For MPX, this leads to the most permissive state and means we > > silently lose bounds violations. I think this would also mean > > that we could lose *ANY* FPU/SSE/AVX state. I'm not sure why > > no one has spotted this bug. > > FWIW, I looked at this a little more today. > > We lose all extended state for our "extended xfeatures", also known as > state component numbers >=2 (AVX, MPX, AVX-512, PKEYs)... But we retain > the state for FP/SSE state. So we lose the top half of the AVX > registers (the bottom half are SSE state). > > I also did a little objdump'ing and grep'ing in a 32-bit distro. > There's no sign of actual use of the ymm registers. > > Basically, it appears nobody has taken a 64-bit Sandybridge or later > CPU, put a 32-bit distro on it that had a >=3.7 kernel on it and tried > to use AVX instructions. Or, if they did, they got random corruption > and gave up before actually diagnosing the problem. :) Weird: putting a 32-bit distro on such a fine piece of 64-bit hardware is pure masochism - and such masochism would also imply the willingness to track down random corruptions! ;-) Thanks, Ingo