From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752698AbbDVEzO (ORCPT ); Wed, 22 Apr 2015 00:55:14 -0400 Received: from mga11.intel.com ([192.55.52.93]:61457 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752458AbbDVEzM (ORCPT ); Wed, 22 Apr 2015 00:55:12 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,621,1422950400"; d="scan'208";a="698952238" From: "Fenghua Yu" To: "H. Peter Anvin" , "Ingo Molnar" , "Thomas Gleixner" , "Asit K Mallick" , "Dave Hansen" , "Glenn Williamson" Cc: "linux-kernel" , "x86" , "Fenghua Yu" Subject: [PATCH Bugfix v2 0/4] x86/xsave/xsaves: Fix a few xsave/xsaves related bugs Date: Tue, 21 Apr 2015 21:51:55 -0700 Message-Id: <1429678319-61356-1-git-send-email-fenghua.yu@intel.com> X-Mailer: git-send-email 1.8.0.1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Fenghua Yu This patchset is supposed to fix some xsave/xsaves related issues. The patch 1/4 fixes an xstate offsets and sizes enumeration issue. During enumerating offsets and sizes starting from 2 to the last enabled feature, if one xstate's size is 0, current code thinks there is no other xstate after this xstate and breaks from enumeration. This is not true because architecturally it's possible to have a few xstates disabled between xstate 2 and the last enabled xstate. The offsets and sizes of the xstates that are not enumerated after the disabled xstate will be consumed and cause issues in runtime. The patch 2/4 introduces a new global variable "user_xstate_size". This variable is used for standard formatted xsave area size in signal frame. Current code incorrectly uses the smaller compacted formatted xsave area size for signal frame and will cause issues in xstate access in signal frame. The patch 3/4 is not fixing a bug. But it renames "xstate_size" to "kernel_xstate_size" to explicitly distinguish between xstate size in kernel space and the one in user space. It just makes kernel code more clear. The patch 4/4 claims that the structure of xsave_struct is non-architectural and fields/xstates in the structure is not defined in compilation time. No new states should be added in xsave_struct. The xsave area should be constructed during kernel booting time. We may hit the issues on either existing platforms or upcoming platforms. We had better to have the patches in upstream and backport them to stable kernel and distros. Fenghua Yu (4): x86/xsave.c: Fix xstate offsets and sizes enumeration x86/xsaves: Define and use user_xstate_size for xstate size in signal context x86/xsaves: Rename xstate_size to kernel_xstate_size to explicitly distinguish xstate size in kernel from user space x86/xsave: Don't add new states in xsave_struct arch/x86/include/asm/fpu-internal.h | 7 ++- arch/x86/include/asm/processor.h | 23 +++---- arch/x86/include/asm/xsave.h | 1 - arch/x86/kernel/i387.c | 18 +++--- arch/x86/kernel/process.c | 2 +- arch/x86/kernel/xsave.c | 120 +++++++++++++++++++++++++++++------- 6 files changed, 118 insertions(+), 53 deletions(-) -- 1.8.1.2