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 v6 01/13] x86/xsaves: Define and use fpu_user_xstate_size
Date: Wed, 11 May 2016 19:20:45 +0200	[thread overview]
Message-ID: <20160511172045.GH2180@pd.tnic> (raw)
In-Reply-To: <f2e6daf2dc48724cc06250002dc01ac6b30339c1.1462914897.git.yu-cheng.yu@intel.com>

On Tue, May 10, 2016 at 04:29:53PM -0700, Yu-cheng Yu wrote:
> The XSAVE area of kernel can be in standard or compacted format;

"The kernel xstate area... "

and can we call it the xstate area as there are a bunch of XSAVE*
insns touching it. The file which deals with it is even called that:
arch/x86/kernel/fpu/xstate.c

> it is always in standard format for user mode. When XSAVES is
> enabled, the kernel uses the compacted format and it is necessary
> to use a separate fpu_user_xstate_size for signal/ptrace frames.
> 
> Based on an earlier patch from Fenghua Yu <fenghua.yu@intel.com>
> 
> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> [yu-cheng.yu@intel.com: rebase to current, rename to fpu_user_xstate_size]
> Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> Reviewed-by: Dave Hansen <dave.hansen@intel.com>

Maybe I wasn't as clear as I hoped to be. Let me be more specific:

So you either need to do:

---
From: Fenghua

...

Signed-off-by: Fenghua
Signed-off-by: You
...
---

or

---

Based on an earlier patch from Fenghua Yu <fenghua.yu@intel.com>.

Signed-off-by: You

---

with the second variant making you the author implicitly because you're
the sender.

Makes more sense this way?

> ---
>  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      | 27 ++++++++++----
>  arch/x86/kernel/fpu/xstate.c      | 76 ++++++++++++++++++++++++---------------
>  5 files changed, 73 insertions(+), 37 deletions(-)

...

> diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
> index b48ef35..dfac87d 100644
> --- a/arch/x86/kernel/fpu/xstate.c
> +++ b/arch/x86/kernel/fpu/xstate.c
> @@ -44,6 +44,13 @@ static unsigned int xstate_sizes[XFEATURE_MAX]   = { [ 0 ... XFEATURE_MAX - 1] =
>  static unsigned int xstate_comp_offsets[sizeof(xfeatures_mask)*8];
>  
>  /*
> + * The XSAVE area of kernel can be in standard or compacted format;

"The kernel xstate area... "

> + * it is always in standard format for user mode. This is the user
> + * mode standard format size used for signal and ptrace frames.
> + */

But yes, that's very nice commenting.

> +unsigned int fpu_user_xstate_size;
> +
> +/*
>   * Clear all of the X86_FEATURE_* bits that are unavailable
>   * when the CPU has no XSAVE support.
>   */

...

> @@ -591,7 +598,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)

So next time you submit patches against -tip, please merge them with
tip/master and see if they still build, at least.

During last review I told you to use boot_cpu_has(X86_FEATURE_XSAVES)
because those cpu_has_XXX things are going away and are gone in tip
already.

Please be more careful when incorporating review comments - otherwise it
is waste of both yours and reviewer's time.

Thanks.

-- 
Regards/Gruss,
    Boris.

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

  reply	other threads:[~2016-05-11 17:20 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-10 23:29 [PATCH v6 00/13] x86/xsaves: Fix XSAVES issues Yu-cheng Yu
2016-05-10 23:29 ` [PATCH v6 01/13] x86/xsaves: Define and use fpu_user_xstate_size Yu-cheng Yu
2016-05-11 17:20   ` Borislav Petkov [this message]
2016-05-11 17:25     ` Yu, Fenghua
2016-05-11 17:32       ` Borislav Petkov
2016-05-12  6:35       ` Ingo Molnar
2016-05-10 23:29 ` [PATCH v6 02/13] x86/xsaves: Rename xstate_size to fpu_kernel_xstate_size to distinguish from fpu_user_xstate_size Yu-cheng Yu
2016-05-10 23:29 ` [PATCH v6 03/13] x86/xsaves: Keep init_fpstate.xsave.header.xfeatures as zero for init optimization Yu-cheng Yu
2016-05-10 23:29 ` [PATCH v6 04/13] x86/xsaves: Introduce a new check that allows correct xstates copy from kernel to user directly Yu-cheng Yu
2016-05-10 23:29 ` [PATCH v6 05/13] x86/xsaves: Align xstate components according to CPUID Yu-cheng Yu
2016-05-10 23:29 ` [PATCH v6 06/13] x86/xsaves: Supervisor state component offset Yu-cheng Yu
2016-05-10 23:29 ` [PATCH v6 07/13] x86/xsaves: Fix PTRACE frames for XSAVES Yu-cheng Yu
2016-05-11 14:50   ` Dave Hansen
2016-05-11 15:16     ` Ingo Molnar
2016-05-10 23:30 ` [PATCH v6 08/13] x86/xsaves: Fix XSTATE component offset print out Yu-cheng Yu
2016-05-10 23:30 ` [PATCH v6 09/13] x86/xsaves: Fix xstate_offsets, xstate_sizes for non-extended states Yu-cheng Yu
2016-05-10 23:30 ` [PATCH v6 10/13] x86/xsaves: Fix __fpu_restore_sig() for XSAVES Yu-cheng Yu
2016-05-10 23:30 ` [PATCH v6 11/13] x86/xsaves: When a disabled xstate component offset is requested, return NULL Yu-cheng Yu
2016-05-10 23:30 ` [PATCH v6 12/13] x86/xsaves: Fix fpstate_init() for XRSTORS Yu-cheng Yu
2016-05-10 23:30 ` [PATCH v6 13/13] x86/xsaves: Re-enable XSAVES Yu-cheng Yu
2016-05-11  4:17 ` [PATCH v6 00/13] x86/xsaves: Fix XSAVES issues Borislav Petkov
2016-05-11 20:03   ` Yu-cheng Yu
2016-05-11 20:12     ` Borislav Petkov
2016-05-12  6:41 ` 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=20160511172045.GH2180@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.