
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	Fri Oct  8 13:36:26 2004
+++ 25-akpm/arch/i386/oprofile/nmi_int.c	Fri Oct  8 13:36:26 2004
@@ -311,7 +311,7 @@ struct oprofile_operations nmi_ops = {
 
 static int __init p4_init(void)
 {
-	__u8 cpu_model = current_cpu_data.x86_model;
+	__u8 cpu_model = boot_cpu_data.x86_model;
 
 	if (cpu_model > 3)
 		return 0;
@@ -342,7 +342,7 @@ static int __init p4_init(void)
 
 static int __init ppro_init(void)
 {
-	__u8 cpu_model = current_cpu_data.x86_model;
+	__u8 cpu_model = boot_cpu_data.x86_model;
 
 	if (cpu_model > 0xd)
 		return 0;
@@ -366,8 +366,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;
  
 	if (!cpu_has_apic)
 		return -ENODEV;
_
