
From: Ingo Molnar <mingo@elte.hu>

Clean up a few suspicious-looking uses of smp_processor_id() in preemptible
code.

The current_cpu_data use is unclean but most likely safe.  I haven't seen any
outright bugs.  Since oprofile does not seem to be ready for different-type
CPUs (do we even care?), the patch below documents this property by using
boot_cpu_data.

Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 25-akpm/arch/i386/oprofile/nmi_int.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff -puN arch/i386/oprofile/nmi_int.c~oprofile-smp_processor_id-fixes arch/i386/oprofile/nmi_int.c
--- 25/arch/i386/oprofile/nmi_int.c~oprofile-smp_processor_id-fixes	Tue Nov  9 13:56:40 2004
+++ 25-akpm/arch/i386/oprofile/nmi_int.c	Tue Nov  9 13:56:57 2004
@@ -302,7 +302,7 @@ static int nmi_create_files(struct super
  
 static int __init p4_init(char ** cpu_type)
 {
-	__u8 cpu_model = current_cpu_data.x86_model;
+	__u8 cpu_model = boot_cpu_data.x86_model;
 
 	if (cpu_model > 3)
 		return 0;
@@ -333,7 +333,7 @@ static int __init p4_init(char ** cpu_ty
 
 static int __init ppro_init(char ** cpu_type)
 {
-	__u8 cpu_model = current_cpu_data.x86_model;
+	__u8 cpu_model = boot_cpu_data.x86_model;
 
 	if (cpu_model > 0xd)
 		return 0;
@@ -357,8 +357,8 @@ static int using_nmi;
 
 int __init nmi_init(struct oprofile_operations *ops)
 {
-	__u8 vendor = current_cpu_data.x86_vendor;
-	__u8 family = current_cpu_data.x86;
+	__u8 vendor = boot_cpu_data.x86_vendor;
+	__u8 family = boot_cpu_data.x86;
 	char *cpu_type;
 
 	if (!cpu_has_apic)
_
