From: "Fenghua Yu" <fenghua.yu@intel.com>
To: "H. Peter Anvin" <hpa@linux.intel.com>,
"Ingo Molnar" <mingo@elte.hu>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Dave Hansen" <dave.hansen@intel.com>,
"Asit K Mallick" <asit.k.mallick@intel.com>,
"Glenn Williamson" <glenn.p.williamson@intel.com>
Cc: "linux-kernel" <linux-kernel@vger.kernel.org>,
"x86" <x86@kernel.org>, "Fenghua Yu" <fenghua.yu@intel.com>
Subject: [PATCH v3 Bugfix 0/6] xstate/fpu bug fixes
Date: Fri, 8 May 2015 14:30:59 -0700 [thread overview]
Message-ID: <1431120665-36841-1-git-send-email-fenghua.yu@intel.com> (raw)
From: Fenghua Yu <fenghua.yu@intel.com>
This patchset is supposed to fix some xsave/xsaves/fpu related issues.
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.
The patch 1/6 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/6 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/6 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/6 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.
The patch 5/6 clears xstate_bv so that init optimization in hardware
can take action. Without the patch, some xstates are always not in
init status and this will impact badly on performance of context
switch.
The patch 6/6 introduces a correct check for user_has_fpu check.
Changes in v3:
1/6: In description, add that Ingo has a same patch in his xstate/fpu
overall clean up patchset.
2/6: Remove copy_to_user_xstate(). Now copy compact format xsave
area directly from processor to user buffer in 6/6.
Initialize user_xstate_size in init_thread_xstate().
3/6: Add Dave Hansen's credit in description.
5/6: Add this new patch for performance issue.
6/6: Add this new patch for a new user_has_fpu check to allow copy
compact format xsave area directly from processor to user buffer.
Fenghua Yu (6):
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
x86/xsaves: Keep xstate_bv in init_xstate_buf header as zero for init
optimimization
x86/xsave.c: Introduce a new check that allows correct xstates copy
from kernel to user directly
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 | 21 ++++----
arch/x86/kernel/process.c | 2 +-
arch/x86/kernel/xsave.c | 105 ++++++++++++++++++++++++++----------
6 files changed, 102 insertions(+), 57 deletions(-)
--
1.8.1.2
next reply other threads:[~2015-05-08 21:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-08 21:30 Fenghua Yu [this message]
2015-05-08 21:31 ` [PATCH v3 Bugfix 1/6] x86/xsave.c: Fix xstate offsets and sizes enumeration Fenghua Yu
2015-05-08 21:31 ` [PATCH v3 Bugfix 2/6] x86/xsaves: Define and use user_xstate_size for xstate size in signal context Fenghua Yu
2015-05-08 21:31 ` [PATCH v3 Bugfix 3/6] x86/xsaves: Rename xstate_size to kernel_xstate_size to explicitly distinguish xstate size in kernel from user space Fenghua Yu
2015-05-08 21:31 ` [PATCH v3 Bugfix 4/6] x86/xsave: Don't add new states in xsave_struct Fenghua Yu
2015-05-08 21:31 ` [PATCH v3 Bugfix 5/6] x86/xsaves: Keep xstate_bv in init_xstate_buf header as zero for init optimimization Fenghua Yu
2015-05-08 21:31 ` [PATCH v3 Bugfix 6/6] x86/xsave.c: Introduce a new check that allows correct xstates copy from kernel to user directly Fenghua Yu
2015-05-09 6:09 ` [PATCH v3 Bugfix 0/6] xstate/fpu bug fixes Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1431120665-36841-1-git-send-email-fenghua.yu@intel.com \
--to=fenghua.yu@intel.com \
--cc=asit.k.mallick@intel.com \
--cc=dave.hansen@intel.com \
--cc=glenn.p.williamson@intel.com \
--cc=hpa@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome