Skip to contentSkip to conversation

x86: drop unnecessary kernel_eflags variable from 64 bit

RFC In review Cyrill Gorcunov 3 participants 5 messages Aug 24, 2012 – Sep 14, 2012 x86

lore
Share & tools
lore
#0 lore raw

RFC 1/1 x86: drop unnecessary kernel_eflags variable from 64 bit

Hi guys,

I've been looking for some particular email in my mailbox when found the patch below (it's dated as August 2011 ;) and think it's still valid for kernel. Actually there were two patches, and the second patch was unifying x86-32 with x86-64 but it was doable as far as I remember.

Anyway, take a look. For debug purpose I've been runing the kernel on a machine with 2 cpus and when cpus were starting we're rewritting the kernel_eflags as many times as much cpus we have. My debug code printed out

[root@neptune ~]# dmesg | grep "eflags"

[   18.459686] cpu_init: kernel_eflags: 46
[   18.782908] cpu_init: kernel_eflags: 46

[root@neptune ~]#

As you may see it has pf and zf flags set, which I suppose do not mean much for code where we use this variable, ie in ret_from_fork. The interrupts are off though as expected.

The patch below does substitude this variable with hard-coded value in a manner of x86-32 code. The only concern I have is that -- since this `kernel_eflags' was there, it must be a reason why it was introduced in first place and I failed to figure out why. Perhaps I need to digg though linux early time when x86-64 support was introduced?

Cyrill
---
From: Ian Campbell <[email protected]>
Subject: [RFC] x86: drop unnecessary kernel_eflags variable from 64 bit

On 64 bit x86 we save the current eflags in cpu_init for use in ret_from_fork. Strictly speaking reserved bits in EFLAGS should be read as written but in practise it is unlikely that EFLAGS could ever be extended in this way and the kernel alread clears any undefined flags early on.

The equivalent 32 bit code simply hard codes 0x0202 as the new EFLAGS.

This change makes 64 bit use the same mechanism to setup the initial EFLAGS on fork. Note that 64 bit resets EFLAGS before calling schedule_tail() as opposed to 32 bit which calls schedule_tail() first. Therefore the correct value for EFLAGS has opposite IF bit.

CC "H. Peter Anvin" <[email protected]>
CC Ingo Molnar <[email protected]>
CC Thomas Gleixner <[email protected]>
CC Brian Gerst <[email protected]>
CC Peter Zijlstra <[email protected]>
CC Pekka Enberg <[email protected]>
CC Andi Kleen <[email protected]>
---
 arch/x86/include/asm/processor.h |    1 -
 arch/x86/kernel/cpu/common.c     |    4 ----
 arch/x86/kernel/entry_64.S       |    2 +-
 3 files changed, 1 insertion(+), 6 deletions(-)
arch/x86/include/asm/processor.h +0 -1
Index: linux-2.6.git/arch/x86/include/asm/processor.h
===================================================================
@@ -423,7 +423,6 @@ DECLARE_INIT_PER_CPU(irq_stack_union);
 
 DECLARE_PER_CPU(char *, irq_stack_ptr);
 DECLARE_PER_CPU(unsigned int, irq_count);
-extern unsigned long kernel_eflags;
 extern asmlinkage void ignore_sysret(void);
 #else	/* X86_64 */
 #ifdef CONFIG_CC_STACKPROTECTOR
arch/x86/kernel/cpu/common.c +0 -4
Index: linux-2.6.git/arch/x86/kernel/cpu/common.c
===================================================================
@@ -1114,8 +1114,6 @@ void syscall_init(void)
 	       X86_EFLAGS_TF|X86_EFLAGS_DF|X86_EFLAGS_IF|X86_EFLAGS_IOPL);
 }
 
-unsigned long kernel_eflags;
-
 /*
  * Copies of the original ist values from the tss are only accessed during
  * debugging, no special alignment required.
@@ -1297,8 +1295,6 @@ void __cpuinit cpu_init(void)
 	fpu_init();
 	xsave_init();
 
-	raw_local_save_flags(kernel_eflags);
-
 	if (is_uv_system())
 		uv_cpu_init();
 }
arch/x86/kernel/entry_64.S +1 -1
Index: linux-2.6.git/arch/x86/kernel/entry_64.S
===================================================================
@@ -440,7 +440,7 @@ ENTRY(ret_from_fork)
 
 	LOCK ; btr $TIF_FORK,TI_flags(%r8)
 
-	pushq_cfi kernel_eflags(%rip)
+	pushq_cfi $0x0002
 	popfq_cfi				# reset kernel eflags
 
 	call schedule_tail			# rdi: 'prev' task parameter
Acked-by on v1 1/1
#2 lore raw
In reply to Cyrill Gorcunov
Quoted 7 lines · Cyrill Gorcunov

Hi guys,

I've been looking for some particular email in my mailbox when found the patch below (it's dated as August 2011 ;) and think it's still valid for kernel. Actually there were two patches, and the second patch was unifying x86-32 with x86-64 but it was doable as far as I remember.

Patch is fine for me. I did the original code, but you're right it's unlikely the EFLAGS will ever be extended.

-Andi

#3 lore raw
Quoted 9 lines · Andi Kleen
Quoted 7 lines · Cyrill Gorcunov

Hi guys,

I've been looking for some particular email in my mailbox when found the patch below (it's dated as August 2011 ;) and think it's still valid for kernel. Actually there were two patches, and the second patch was unifying x86-32 with x86-64 but it was doable as far as I remember.

Quoted 4 lines

Patch is fine for me. I did the original code, but you're right it's unlikely the EFLAGS will ever be extended.

Thanks for review, Andi!

#4 lore raw

[tip:x86/asm] x86: Drop unnecessary kernel_eflags variable on 64-bit

In reply to Cyrill Gorcunov
Commit-ID:  6eebdda35e6b18d0dddb2a44e34211bd94f0cad6
Gitweb:     http://git.kernel.org/tip/6eebdda35e6b18d0dddb2a44e34211bd94f0cad6
Author:     Ian Campbell <[email protected]>
AuthorDate: Fri, 24 Aug 2012 23:58:47 +0400
Committer:  Ingo Molnar <[email protected]>
CommitDate: Thu, 13 Sep 2012 17:32:47 +0200

x86: Drop unnecessary kernel_eflags variable on 64-bit

On 64 bit x86 we save the current eflags in cpu_init for use in ret_from_fork. Strictly speaking reserved bits in EFLAGS should be read as written but in practise it is unlikely that EFLAGS could ever be extended in this way and the kernel alread clears any undefined flags early on.

The equivalent 32 bit code simply hard codes 0x0202 as the new EFLAGS.

This change makes 64 bit use the same mechanism to setup the initial EFLAGS on fork. Note that 64 bit resets EFLAGS before calling schedule_tail() as opposed to 32 bit which calls schedule_tail() first. Therefore the correct value for EFLAGS has opposite IF bit.

---
 arch/x86/include/asm/processor.h |    1 -
 arch/x86/kernel/cpu/common.c     |    4 ----
 arch/x86/kernel/entry_64.S       |    2 +-
 3 files changed, 1 insertions(+), 6 deletions(-)
arch/x86/include/asm/processor.h +0 -1
index d048cad..9738b39 100644
@@ -423,7 +423,6 @@ DECLARE_INIT_PER_CPU(irq_stack_union);
 
 DECLARE_PER_CPU(char *, irq_stack_ptr);
 DECLARE_PER_CPU(unsigned int, irq_count);
-extern unsigned long kernel_eflags;
 extern asmlinkage void ignore_sysret(void);
 #else	/* X86_64 */
 #ifdef CONFIG_CC_STACKPROTECTOR
arch/x86/kernel/cpu/common.c +0 -4
index a5fbc3c..9961e2e 100644
@@ -1116,8 +1116,6 @@ void syscall_init(void)
 	       X86_EFLAGS_TF|X86_EFLAGS_DF|X86_EFLAGS_IF|X86_EFLAGS_IOPL);
 }
 
-unsigned long kernel_eflags;
-
 /*
  * Copies of the original ist values from the tss are only accessed during
  * debugging, no special alignment required.
@@ -1299,8 +1297,6 @@ void __cpuinit cpu_init(void)
 	fpu_init();
 	xsave_init();
 
-	raw_local_save_flags(kernel_eflags);
-
 	if (is_uv_system())
 		uv_cpu_init();
 }
arch/x86/kernel/entry_64.S +1 -1
index 69babd8..b1dac12 100644
@@ -440,7 +440,7 @@ ENTRY(ret_from_fork)
 
 	LOCK ; btr $TIF_FORK,TI_flags(%r8)
 
-	pushq_cfi kernel_eflags(%rip)
+	pushq_cfi $0x0002
 	popfq_cfi				# reset kernel eflags
 
 	call schedule_tail			# rdi: 'prev' task parameter