Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1398593 > unrolled thread

[PATCH v6 00/13] x86/xsaves: Fix XSAVES issues

Back to article view | Back to linux.kernel

Contents

  [PATCH v6 00/13] x86/xsaves: Fix XSAVES issues Yu-cheng Yu <yu-cheng.yu@intel.com> - 2016-05-11 01:40 +0200
    Re: [PATCH v6 00/13] x86/xsaves: Fix XSAVES issues Borislav Petkov <bp@suse.de> - 2016-05-11 06:20 +0200
      Re: [PATCH v6 00/13] x86/xsaves: Fix XSAVES issues Yu-cheng Yu <yu-cheng.yu@intel.com> - 2016-05-11 22:10 +0200
        Re: [PATCH v6 00/13] x86/xsaves: Fix XSAVES issues Borislav Petkov <bp@suse.de> - 2016-05-11 22:20 +0200
    Re: [PATCH v6 00/13] x86/xsaves: Fix XSAVES issues Ingo Molnar <mingo@kernel.org> - 2016-05-12 08:50 +0200

#1398593 — [PATCH v6 00/13] x86/xsaves: Fix XSAVES issues

XSAVES is a kernel-mode instruction. It offers a compacted format and
memory-write optimization. These patches fix issues in the first
implementation.

Changes since Version 5:

Patch 1, 2 - Change names to fpu_user_xstate_size and fpu_kernel_xstate_size;
             fix some comments, etc.

Patch 11 - In addition to a warning, make __raw_xsave_addr() return NULL
           when a disabled xstate component address is requested.

Patch 12 - Add more details in the comments of why this patch is needed;
           make a new macro for xcomp_bv[63].

Yu-cheng Yu (13):
  x86/xsaves: Define and use fpu_user_xstate_size
  x86/xsaves: Rename xstate_size to fpu_kernel_xstate_size to
    distinguish from fpu_user_xstate_size
  x86/xsaves: Keep init_fpstate.xsave.header.xfeatures as zero for init
    optimization
  x86/xsaves: Introduce a new check that allows correct xstates copy
    from kernel to user directly
  x86/xsaves: Align xstate components according to CPUID
  x86/xsaves: Supervisor state component offset
  x86/xsaves: Fix PTRACE frames for XSAVES
  x86/xsaves: Fix XSTATE component offset print out
  x86/xsaves: Fix xstate_offsets, xstate_sizes for non-extended states
  x86/xsaves: Fix __fpu_restore_sig() for XSAVES
  x86/xsaves: When a disabled xstate component offset is requested,
    return NULL
  x86/xsaves: Fix fpstate_init() for XRSTORS
  x86/xsaves: Re-enable XSAVES

 arch/x86/include/asm/fpu/types.h  |   7 +
 arch/x86/include/asm/fpu/xstate.h |  10 +-
 arch/x86/include/asm/processor.h  |   3 +-
 arch/x86/kernel/fpu/core.c        |  11 +-
 arch/x86/kernel/fpu/init.c        |  34 ++--
 arch/x86/kernel/fpu/regset.c      |  56 +++--
 arch/x86/kernel/fpu/signal.c      |  43 +++-
 arch/x86/kernel/fpu/xstate.c      | 417 ++++++++++++++++++++++++++++++--------
 8 files changed, 440 insertions(+), 141 deletions(-)

-- 
1.9.1

[toc] | [next] | [standalone]

#1398682

On Tue, May 10, 2016 at 04:29:52PM -0700, Yu-cheng Yu wrote:
> XSAVES is a kernel-mode instruction. It offers a compacted format and
> memory-write optimization. These patches fix issues in the first
> implementation.
> 
> Changes since Version 5:

Please, for the future, do send your patchset roughly only once a week -
you just sent v5 a day or two ago without giving proper time to people
(me?) to review them all. Consult Documentation/SubmittingPatches if
there are doubts.

Thanks.

-- 
Regards/Gruss,
    Boris.

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

[toc] | [prev] | [next] | [standalone]

#1399483

On Wed, May 11, 2016 at 06:17:41AM +0200, Borislav Petkov wrote:
> Please, for the future, do send your patchset roughly only once a week -
> you just sent v5 a day or two ago without giving proper time to people
> (me?) to review them all. Consult Documentation/SubmittingPatches if
> there are doubts.

There are no actual functional changes. I wanted to respond to comments
quickly. I will try to be normal next time :-)

Yu-cheng

[toc] | [prev] | [next] | [standalone]

#1399488

On Wed, May 11, 2016 at 01:03:37PM -0700, Yu-cheng Yu wrote:
> There are no actual functional changes. I wanted to respond to
> comments quickly.

This is not how you respond to comments quickly - you wait roughly a
week until people have had time to review the whole thing and *then* you
send again. Spamming people with a patchset everyday will make most of
them not look at your stuff anymore.

And go read Documentation/SubmittingPatches already because I'm tired of
typing the same things over and over again.

-- 
Regards/Gruss,
    Boris.

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

[toc] | [prev] | [next] | [standalone]

#1399692

* Yu-cheng Yu <yu-cheng.yu@intel.com> wrote:

> XSAVES is a kernel-mode instruction. It offers a compacted format and
> memory-write optimization. These patches fix issues in the first
> implementation.
> 
> Changes since Version 5:
> 
> Patch 1, 2 - Change names to fpu_user_xstate_size and fpu_kernel_xstate_size;
>              fix some comments, etc.
> 
> Patch 11 - In addition to a warning, make __raw_xsave_addr() return NULL
>            when a disabled xstate component address is requested.
> 
> Patch 12 - Add more details in the comments of why this patch is needed;
>            make a new macro for xcomp_bv[63].
> 
> Yu-cheng Yu (13):
>   x86/xsaves: Define and use fpu_user_xstate_size

So if you look at the git log of arch/x86/kernel/fpu/ then you'll see that the 
standard tag for FPU code is 'x86/fpu: ', for purely xstate related patch it's 
'x86/fpu/xstate: '.

>   x86/xsaves: Rename xstate_size to fpu_kernel_xstate_size to distinguish from fpu_user_xstate_size
>   x86/xsaves: Keep init_fpstate.xsave.header.xfeatures as zero for init optimization
>   x86/xsaves: Introduce a new check that allows correct xstates copy from kernel to user directly
>   x86/xsaves: Align xstate components according to CPUID
>   x86/xsaves: Supervisor state component offset

Please start all commit titles with verbs.

Also, this series is clearly too big. I was under the impression that the series 
was ready, but there's a number of small details that were pointed out (none of 
them very serious) - so how about you send a series of the first 4 patches next 
time around, and only send another 4 once those 4 first patches get applied to 
x86/fpu?

This makes it much easier to review, which reduces reviewer frustration; and it 
also allows you to focus more on incorporating feedback, without having to juggle 
13 patches all the time.

Ok?

Thanks,

	Ingo

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web