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

Groups > linux.kernel > #1612145 > unrolled thread

[PATCH v2 1/2] x86/boot/32: Delete cpuinfo_x86::wp_works_ok

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.

Contents

  [PATCH v2 1/2] x86/boot/32: Delete cpuinfo_x86::wp_works_ok Andy Lutomirski <luto@kernel.org> - 2017-03-29 18:50 +0200
    Re: [PATCH v2 1/2] x86/boot/32: Delete cpuinfo_x86::wp_works_ok Borislav Petkov <bp@alien8.de> - 2017-03-29 22:30 +0200
      Re: [PATCH v2 1/2] x86/boot/32: Delete cpuinfo_x86::wp_works_ok Andy Lutomirski <luto@amacapital.net> - 2017-03-29 23:10 +0200
        Re: [PATCH v2 1/2] x86/boot/32: Delete cpuinfo_x86::wp_works_ok Ingo Molnar <mingo@kernel.org> - 2017-03-30 09:10 +0200

#1612145 — [PATCH v2 1/2] x86/boot/32: Delete cpuinfo_x86::wp_works_ok

Linux refuses to boot if WP doesn't work okay, so tracking whether
it works serves no purpose.  The only use I can see at all for wp_works_ok
is that it lets Xen bypass test_wp_bit().  If this is truly needed,
it could be more cleanly handled using X86_FEATURE_XENPV, but it
looks like Xen can handle test_wp_bit() correctly without special
cases at all.

Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
 arch/x86/include/asm/processor.h |  2 --
 arch/x86/kernel/cpu/proc.c       |  5 ++---
 arch/x86/kernel/setup.c          |  2 --
 arch/x86/mm/init_32.c            | 13 +++++--------
 arch/x86/xen/enlighten.c         |  1 -
 5 files changed, 7 insertions(+), 16 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 05319c60b3db..1ac08e96411c 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -90,8 +90,6 @@ struct cpuinfo_x86 {
 	__u8			x86_model;
 	__u8			x86_mask;
 #ifdef CONFIG_X86_32
-	char			wp_works_ok;	/* It doesn't on 386's */
-
 	/* Problems on some 486Dx4's and old 386's: */
 	char			rfu;
 	char			pad0;
diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index 18ca99f2798b..6df621ae62a7 100644
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -31,14 +31,13 @@ static void show_cpuinfo_misc(struct seq_file *m, struct cpuinfo_x86 *c)
 		   "fpu\t\t: %s\n"
 		   "fpu_exception\t: %s\n"
 		   "cpuid level\t: %d\n"
-		   "wp\t\t: %s\n",
+		   "wp\t\t: yes\n",
 		   static_cpu_has_bug(X86_BUG_FDIV) ? "yes" : "no",
 		   static_cpu_has_bug(X86_BUG_F00F) ? "yes" : "no",
 		   static_cpu_has_bug(X86_BUG_COMA) ? "yes" : "no",
 		   static_cpu_has(X86_FEATURE_FPU) ? "yes" : "no",
 		   static_cpu_has(X86_FEATURE_FPU) ? "yes" : "no",
-		   c->cpuid_level,
-		   c->wp_works_ok ? "yes" : "no");
+		   c->cpuid_level);
 }
 #else
 static void show_cpuinfo_misc(struct seq_file *m, struct cpuinfo_x86 *c)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 56b1177155db..462b7c69443d 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -175,11 +175,9 @@ static struct resource bss_resource = {
 #ifdef CONFIG_X86_32
 /* cpu data as detected by the assembly code in head.S */
 struct cpuinfo_x86 new_cpu_data = {
-	.wp_works_ok = -1,
 };
 /* common cpu data for all cpus */
 struct cpuinfo_x86 boot_cpu_data __read_mostly = {
-	.wp_works_ok = -1,
 };
 EXPORT_SYMBOL(boot_cpu_data);
 
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index 5ed3c141bbd5..b30f20951e9e 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -731,15 +731,13 @@ static void __init test_wp_bit(void)
 
 	/* Any page-aligned address will do, the test is non-destructive */
 	__set_fixmap(FIX_WP_TEST, __pa(&swapper_pg_dir), PAGE_KERNEL_RO);
-	boot_cpu_data.wp_works_ok = do_test_wp_bit();
-	clear_fixmap(FIX_WP_TEST);
-
-	if (!boot_cpu_data.wp_works_ok) {
+	if (!do_test_wp_bit()) {
 		printk(KERN_CONT "No.\n");
 		panic("Linux doesn't support CPUs with broken WP.");
-	} else {
-		printk(KERN_CONT "Ok.\n");
 	}
+	clear_fixmap(FIX_WP_TEST);
+
+	printk(KERN_CONT "Ok.\n");
 }
 
 void __init mem_init(void)
@@ -821,8 +819,7 @@ void __init mem_init(void)
 	BUG_ON(VMALLOC_START				>= VMALLOC_END);
 	BUG_ON((unsigned long)high_memory		> VMALLOC_START);
 
-	if (boot_cpu_data.wp_works_ok < 0)
-		test_wp_bit();
+	test_wp_bit();
 }
 
 #ifdef CONFIG_MEMORY_HOTPLUG
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 4951fcf95143..6efa0cc425a2 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1595,7 +1595,6 @@ asmlinkage __visible void __init xen_start_kernel(void)
 	/* set up basic CPUID stuff */
 	cpu_detect(&new_cpu_data);
 	set_cpu_cap(&new_cpu_data, X86_FEATURE_FPU);
-	new_cpu_data.wp_works_ok = 1;
 	new_cpu_data.x86_capability[CPUID_1_EDX] = cpuid_edx(1);
 #endif
 
-- 
2.9.3

[toc] | [next] | [standalone]

#1612297

On Wed, Mar 29, 2017 at 09:48:41AM -0700, Andy Lutomirski wrote:
> Linux refuses to boot if WP doesn't work okay, so tracking whether
> it works serves no purpose.  The only use I can see at all for wp_works_ok
> is that it lets Xen bypass test_wp_bit().  If this is truly needed,
> it could be more cleanly handled using X86_FEATURE_XENPV, but it
> looks like Xen can handle test_wp_bit() correctly without special
> cases at all.
> 
> Signed-off-by: Andy Lutomirski <luto@kernel.org>

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=6415813bae75feba10b8ca3ed6634a72c2a4d313

What's up?

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

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

#1612338

On Wed, Mar 29, 2017 at 1:20 PM, Borislav Petkov <bp@alien8.de> wrote:
> On Wed, Mar 29, 2017 at 09:48:41AM -0700, Andy Lutomirski wrote:
>> Linux refuses to boot if WP doesn't work okay, so tracking whether
>> it works serves no purpose.  The only use I can see at all for wp_works_ok
>> is that it lets Xen bypass test_wp_bit().  If this is truly needed,
>> it could be more cleanly handled using X86_FEATURE_XENPV, but it
>> looks like Xen can handle test_wp_bit() correctly without special
>> cases at all.
>>
>> Signed-off-by: Andy Lutomirski <luto@kernel.org>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=6415813bae75feba10b8ca3ed6634a72c2a4d313
>
> What's up?
>

Wow, I based on tip/x86/mm per Ingo's request, but maybe that was the
wrong branch, and apparently Mathias did the same thing in the mean
time.  Whoops.  I'll rebase again.

> --
> Regards/Gruss,
>     Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.



-- 
Andy Lutomirski
AMA Capital Management, LLC

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

#1612638

* Andy Lutomirski <luto@amacapital.net> wrote:

> On Wed, Mar 29, 2017 at 1:20 PM, Borislav Petkov <bp@alien8.de> wrote:
> > On Wed, Mar 29, 2017 at 09:48:41AM -0700, Andy Lutomirski wrote:
> >> Linux refuses to boot if WP doesn't work okay, so tracking whether
> >> it works serves no purpose.  The only use I can see at all for wp_works_ok
> >> is that it lets Xen bypass test_wp_bit().  If this is truly needed,
> >> it could be more cleanly handled using X86_FEATURE_XENPV, but it
> >> looks like Xen can handle test_wp_bit() correctly without special
> >> cases at all.
> >>
> >> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=6415813bae75feba10b8ca3ed6634a72c2a4d313
> >
> > What's up?
> >
> 
> Wow, I based on tip/x86/mm per Ingo's request, but maybe that was the
> wrong branch, and apparently Mathias did the same thing in the mean
> time.  Whoops.  I'll rebase again.

Oops, I didn't realize the duplication either. The splitting up of the patch that 
I requested made the merge easier I suspect - albeit that's an unintended side 
effect.

Thanks,

	Ingo

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web