All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@suse.de>
To: Yu-cheng Yu <yu-cheng.yu@intel.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>,
	"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>
Subject: Re: [PATCH v5 01/13] x86/xsaves: Define and use user_xstate_size for xstate size in signal context
Date: Tue, 10 May 2016 13:04:41 +0200	[thread overview]
Message-ID: <20160510110441.GA28520@pd.tnic> (raw)
In-Reply-To: <edaed48571a03fd64683248098e6b0ebd2e5cc09.1462816638.git.yu-cheng.yu@intel.com>

On Mon, May 09, 2016 at 01:45:58PM -0700, Yu-cheng Yu wrote:
> If "xsaves" is enabled, kernel always uses compacted format of xsave area.
> But user space still uses standard format of xsave area. Thus, xstate size
> in kernel's xsave area is smaller than xstate size in user's xsave area.
> The xstate in signal frame should be in standard format for user's signal
> handler to access.
> 
> In no "xsaves" case, xsave area in both user space and kernel space are in
> standard format. Therefore, user's and kernel's xstate sizes are equal.
> 
> In "xsaves" case, xsave area in user space is in standard format while
> xsave area in kernel space is in compacted format. Therefore, kernel's
> xstate size is smaller than user's xstate size.

So this repeats what the first paragraph said.

> So here is the problem: currently kernel assumes its own xstate size is
> signal frame's xstate size. This is not a problem in no "xsaves" case.

							 ^
							the

This whole text is missing a bunch of "the"s...

> It is an issue in "xsaves" case because kernel's xstate size is smaller
		   ^			 ^
		 the			the

and so on...


> than user's xstate size. In fpu__alloc_mathframe(), a smaller fpstate
> buffer is allocated for the standard format xstate in signal frame.
> Then kernel saves only part of xstate registers into this smaller
> user's fpstate buffer and user will see part of the xstate registers in
> signal context. Similar issue happens after returning from signal handler:
> kernel will only restore part of xstate registers from user's fpstate
> buffer in signal frame.
> 
> This patch defines and uses user_xstate_size for xstate size in signal
> frame. It's read from returned value in ebx from CPUID leaf 0x0D subleaf
> 0x0. This is maximum size required by enabled states in XCR0 and may be
> different from ecx when states at the end of the xsave area are not
> enabled. This value indicates the size required for XSAVE to save all
> supported user states in legacy/standard format.
> 
> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>

That SOB chain needs clarification: if Fenghua is the author, the patch
should contain his From: at the top. If it is based on an earlier patch
from him, commit message should say:

Based on an earlier patch from Fenghua... without the SOB.

> Reviewed-by: Dave Hansen <dave.hansen@intel.com>
> ---
>  arch/x86/include/asm/fpu/xstate.h |  1 -
>  arch/x86/include/asm/processor.h  |  1 +
>  arch/x86/kernel/fpu/init.c        |  5 ++-
>  arch/x86/kernel/fpu/signal.c      | 26 ++++++++++----
>  arch/x86/kernel/fpu/xstate.c      | 71 ++++++++++++++++++++++++---------------
>  5 files changed, 67 insertions(+), 37 deletions(-)
> 
> diff --git a/arch/x86/include/asm/fpu/xstate.h b/arch/x86/include/asm/fpu/xstate.h
> index 38951b0..16df2c4 100644
> --- a/arch/x86/include/asm/fpu/xstate.h
> +++ b/arch/x86/include/asm/fpu/xstate.h
> @@ -39,7 +39,6 @@
>  #define REX_PREFIX
>  #endif
>  
> -extern unsigned int xstate_size;
>  extern u64 xfeatures_mask;
>  extern u64 xstate_fx_sw_bytes[USER_XSTATE_FX_SW_WORDS];
>  
> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> index 9264476..132b4ca 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -368,6 +368,7 @@ DECLARE_PER_CPU(struct irq_stack *, softirq_stack);
>  #endif	/* X86_64 */
>  
>  extern unsigned int xstate_size;
> +extern unsigned int user_xstate_size;

If this is going to be exported, let's prefix it pls:

fpu_user_xstate_size

or

xstate_user_state_size

or somesuch.

And let's add a comment over its definition what exactly it represents.
I.e., the aspect about the signal frame...

...

> @@ -591,7 +593,15 @@ static bool is_supported_xstate_size(unsigned int test_xstate_size)
>  static int init_xstate_size(void)
>  {
>  	/* Recompute the context size for enabled features: */
> -	unsigned int possible_xstate_size = calculate_xstate_size();
> +	unsigned int possible_xstate_size;
> +	unsigned int xsave_size;
> +
> +	xsave_size = get_xsave_size();
> +
> +	if (cpu_has_xsaves)

	if (boot_cpu_has(X86_FEATURE_XSAVES))

> +		possible_xstate_size = get_xsaves_size();
> +	else
> +		possible_xstate_size = xsave_size;
>  
>  	/* Ensure we have the space to store all enabled: */
>  	if (!is_supported_xstate_size(possible_xstate_size))

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

  reply	other threads:[~2016-05-10 11:04 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-09 20:45 [PATCH v5 00/12] x86/xsaves: Fix XSAVES issues Yu-cheng Yu
2016-05-09 20:45 ` [PATCH v5 01/13] x86/xsaves: Define and use user_xstate_size for xstate size in signal context Yu-cheng Yu
2016-05-10 11:04   ` Borislav Petkov [this message]
2016-05-10 15:59     ` Yu-cheng Yu
2016-05-10 16:29       ` Borislav Petkov
2016-05-10 16:30         ` Yu-cheng Yu
2016-05-09 20:45 ` [PATCH v5 02/13] x86/xsaves: Rename xstate_size to kernel_xstate_size to explicitly distinguish xstate size in kernel from user space Yu-cheng Yu
2016-05-10 17:01   ` Borislav Petkov
2016-05-10 17:08     ` Dave Hansen
2016-05-10 17:26       ` Borislav Petkov
2016-05-10 17:31         ` Dave Hansen
2016-05-09 20:46 ` [PATCH v5 03/13] x86/xsaves: Keep init_fpstate.xsave.header.xfeatures as zero for init optimization Yu-cheng Yu
2016-05-09 20:46 ` [PATCH v5 04/13] x86/xsaves: Introduce a new check that allows correct xstates copy from kernel to user directly Yu-cheng Yu
2016-05-09 22:09   ` Dave Hansen
2016-05-09 20:46 ` [PATCH v5 05/13] x86/xsaves: Align xstate components according to CPUID Yu-cheng Yu
2016-05-09 20:46 ` [PATCH v5 06/13] x86/xsaves: Supervisor state component offset Yu-cheng Yu
2016-05-09 20:46 ` [PATCH v5 07/13] x86/xsaves: Fix PTRACE frames for XSAVES Yu-cheng Yu
2016-05-09 20:46 ` [PATCH v5 08/13] x86/xsaves: Fix XSTATE component offset print out Yu-cheng Yu
2016-05-09 20:46 ` [PATCH v5 09/13] x86/xsaves: Fix xstate_offsets, xstate_sizes for non-extended states Yu-cheng Yu
2016-05-09 20:46 ` [PATCH v5 10/13] x86/xsaves: Fix __fpu_restore_sig() for XSAVES Yu-cheng Yu
2016-05-09 23:43   ` Dave Hansen
2016-05-09 20:46 ` [PATCH v5 11/13] x86/xsaves: Add WARN_ON_FPU() when a disabled xstate component offset is requested for a compacted format Yu-cheng Yu
2016-05-09 23:31   ` Dave Hansen
2016-05-09 23:44     ` Yu-cheng Yu
2016-05-09 23:54       ` Dave Hansen
2016-05-09 20:46 ` [PATCH v5 12/13] x86/xsaves: Fix fpstate_init() for XSAVES Yu-cheng Yu
2016-05-09 23:41   ` Dave Hansen
2016-05-09 23:50     ` Yu-cheng Yu
2016-05-10  0:01       ` Dave Hansen
2016-05-09 20:46 ` [PATCH v5 13/13] x86/xsaves: Re-enable XSAVES Yu-cheng 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=20160510110441.GA28520@pd.tnic \
    --to=bp@suse.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=ravi.v.shankar@intel.com \
    --cc=sai.praneeth.prakhya@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yu-cheng.yu@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.