Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1720319 > unrolled thread
| Started by | Borislav Petkov <bp@suse.de> |
|---|---|
| First post | 2017-08-25 19:50 +0200 |
| Last post | 2017-09-02 19:40 +0200 |
| Articles | 4 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v8 02/28] x86/boot: Relocate definition of the initial state of CR0 Borislav Petkov <bp@suse.de> - 2017-08-25 19:50 +0200
Re: [PATCH v8 02/28] x86/boot: Relocate definition of the initial state of CR0 Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-08-31 06:10 +0200
Re: [PATCH v8 02/28] x86/boot: Relocate definition of the initial state of CR0 Borislav Petkov <bp@suse.de> - 2017-08-31 12:00 +0200
Re: [PATCH v8 02/28] x86/boot: Relocate definition of the initial state of CR0 Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-09-02 19:40 +0200
| From | Borislav Petkov <bp@suse.de> |
|---|---|
| Date | 2017-08-25 19:50 +0200 |
| Subject | Re: [PATCH v8 02/28] x86/boot: Relocate definition of the initial state of CR0 |
| Message-ID | <uiqU3-71g-31@gated-at.bofh.it> |
On Fri, Aug 18, 2017 at 05:27:43PM -0700, Ricardo Neri wrote:
> Both head_32.S and head_64.S utilize the same value to initialize the
> control register CR0. Also, other parts of the kernel might want to access
> to this initial definition (e.g., emulation code for User-Mode Instruction
s/to //
> Prevention uses this state to provide a sane dummy value for CR0 when
> emulating the smsw instruction). Thus, relocate this definition to a
> header file from which it can be conveniently accessed.
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Brian Gerst <brgerst@gmail.com>
> Cc: Dave Hansen <dave.hansen@intel.com>
> Cc: Denys Vlasenko <dvlasenk@redhat.com>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: Josh Poimboeuf <jpoimboe@redhat.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: linux-arch@vger.kernel.org
> Cc: linux-mm@kvack.org
> Suggested-by: Borislav Petkov <bp@alien8.de>
> Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> ---
> arch/x86/include/uapi/asm/processor-flags.h | 6 ++++++
> arch/x86/kernel/head_32.S | 3 ---
> arch/x86/kernel/head_64.S | 3 ---
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/include/uapi/asm/processor-flags.h b/arch/x86/include/uapi/asm/processor-flags.h
> index 185f3d10c194..aae1f2aa7563 100644
> --- a/arch/x86/include/uapi/asm/processor-flags.h
> +++ b/arch/x86/include/uapi/asm/processor-flags.h
> @@ -151,5 +151,11 @@
> #define CX86_ARR_BASE 0xc4
> #define CX86_RCR_BASE 0xdc
>
> +/*
> + * Initial state of CR0 for head_32/64.S
> + */
No need for that comment.
With the minor nitpicks addressed, you can add:
Reviewed-by: Borislav Petkov <bp@suse.de>
Thx.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
[toc] | [next] | [standalone]
| From | Ricardo Neri <ricardo.neri-calderon@linux.intel.com> |
|---|---|
| Date | 2017-08-31 06:10 +0200 |
| Message-ID | <ukoXL-Lg-7@gated-at.bofh.it> |
| In reply to | #1720319 |
On Fri, 2017-08-25 at 19:41 +0200, Borislav Petkov wrote: Thanks Borislav for your feedback! > On Fri, Aug 18, 2017 at 05:27:43PM -0700, Ricardo Neri wrote: > > Both head_32.S and head_64.S utilize the same value to initialize the > > control register CR0. Also, other parts of the kernel might want to access > > to this initial definition (e.g., emulation code for User-Mode Instruction > > s/to // > > > Prevention uses this state to provide a sane dummy value for CR0 when I'll make this change. > > emulating the smsw instruction). Thus, relocate this definition to a > > header file from which it can be conveniently accessed. > > > > Cc: Andrew Morton <akpm@linux-foundation.org> > > Cc: Andy Lutomirski <luto@amacapital.net> > > Cc: Andy Lutomirski <luto@kernel.org> > > Cc: Borislav Petkov <bp@alien8.de> > > Cc: Brian Gerst <brgerst@gmail.com> > > Cc: Dave Hansen <dave.hansen@intel.com> > > Cc: Denys Vlasenko <dvlasenk@redhat.com> > > Cc: H. Peter Anvin <hpa@zytor.com> > > Cc: Josh Poimboeuf <jpoimboe@redhat.com> > > Cc: Linus Torvalds <torvalds@linux-foundation.org> > > Cc: Peter Zijlstra <peterz@infradead.org> > > Cc: Thomas Gleixner <tglx@linutronix.de> > > Cc: linux-arch@vger.kernel.org > > Cc: linux-mm@kvack.org > > Suggested-by: Borislav Petkov <bp@alien8.de> > > Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> > > --- > > arch/x86/include/uapi/asm/processor-flags.h | 6 ++++++ > > arch/x86/kernel/head_32.S | 3 --- > > arch/x86/kernel/head_64.S | 3 --- > > 3 files changed, 6 insertions(+), 6 deletions(-) > > > > diff --git a/arch/x86/include/uapi/asm/processor-flags.h b/arch/x86/include/uapi/asm/processor-flags.h > > index 185f3d10c194..aae1f2aa7563 100644 > > --- a/arch/x86/include/uapi/asm/processor-flags.h > > +++ b/arch/x86/include/uapi/asm/processor-flags.h > > @@ -151,5 +151,11 @@ > > #define CX86_ARR_BASE 0xc4 > > #define CX86_RCR_BASE 0xdc > > > > +/* > > + * Initial state of CR0 for head_32/64.S > > + */ > > No need for that comment. > > With the minor nitpicks addressed, you can add: > > Reviewed-by: Borislav Petkov <bp@suse.de> Thank you! Is it necessary for me to submit a v9 with these updates? Perhaps I can make these updates in branch for the maintainers to pull when/if this series is ack'ed. Thanks and BR, Ricardo
[toc] | [prev] | [next] | [standalone]
| From | Borislav Petkov <bp@suse.de> |
|---|---|
| Date | 2017-08-31 12:00 +0200 |
| Message-ID | <ukuqv-3ZB-23@gated-at.bofh.it> |
| In reply to | #1723796 |
On Wed, Aug 30, 2017 at 09:04:18PM -0700, Ricardo Neri wrote:
> Thank you! Is it necessary for me to submit a v9 with these updates?
> Perhaps I can make these updates in branch for the maintainers to pull
> when/if this series is ack'ed.
Don't do anything and let me go through the rest of them first. It is
too late for this merge window anyway so we can take our time. Once you
receive full feedback from me (and hopefully others) you can send what
looks like to be a final v9 with all feedback incorporated. :-)
Thx.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
[toc] | [prev] | [next] | [standalone]
| From | Ricardo Neri <ricardo.neri-calderon@linux.intel.com> |
|---|---|
| Date | 2017-09-02 19:40 +0200 |
| Message-ID | <ulkyJ-5QR-15@gated-at.bofh.it> |
| In reply to | #1724056 |
On Thu, 2017-08-31 at 11:51 +0200, Borislav Petkov wrote: > On Wed, Aug 30, 2017 at 09:04:18PM -0700, Ricardo Neri wrote: > > Thank you! Is it necessary for me to submit a v9 with these updates? > > Perhaps I can make these updates in branch for the maintainers to pull > > when/if this series is ack'ed. > > Don't do anything and let me go through the rest of them first. It is > too late for this merge window anyway so we can take our time. Once you > receive full feedback from me (and hopefully others) you can send what > looks like to be a final v9 with all feedback incorporated. :-) Sure, I will wait until you (and hopefully others) are done reviewing. Thanks and BR, Ricardo
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web