mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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>,
	"Asit K Mallick" <asit.k.mallick@intel.com>,
	"Dave Hansen" <dave.hansen@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 Bugfix v2 0/4] x86/xsave/xsaves: Fix a few xsave/xsaves related bugs
Date: Tue, 21 Apr 2015 21:51:55 -0700	[thread overview]
Message-ID: <1429678319-61356-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 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


             reply	other threads:[~2015-04-22  4:55 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-22  4:51 Fenghua Yu [this message]
2015-04-22  4:51 ` [PATCH Bugfix v2 1/4] x86/xsave.c: Fix xstate offsets and sizes enumeration Fenghua Yu
2015-04-22  4:51 ` [PATCH Bugfix v2 2/4] x86/xsaves: Define and use user_xstate_size for xstate size in signal context Fenghua Yu
2015-04-22 18:45   ` Dave Hansen
2015-04-22 19:05     ` Yu, Fenghua
2015-04-22 19:34       ` Dave Hansen
2015-04-23  0:06         ` Yu, Fenghua
2015-04-23  0:21           ` Dave Hansen
2015-04-23  0:23             ` Yu, Fenghua
2015-04-23  0:34           ` Dave Hansen
2015-04-23 17:09             ` Yu, Fenghua
2015-04-23 21:32               ` Dave Hansen
2015-04-28 14:28   ` Dave Hansen
2015-04-28 22:09   ` Dave Hansen
2015-04-28 22:11     ` Yu, Fenghua
2015-04-29 13:53   ` Dave Hansen
2015-04-22  4:51 ` [PATCH Bugfix v2 3/4] x86/xsaves: Rename xstate_size to kernel_xstate_size to explicitly distinguish xstate size in kernel from user space Fenghua Yu
2015-04-22  4:51 ` [PATCH Bugfix v2 4/4] x86/xsave: Don't add new states in xsave_struct Fenghua Yu

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=1429678319-61356-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