[PATCH] oprofile smp_processor_id() fixes

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>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

arch/i386/oprofile/nmi_int.c

@@ -302,7 +302,7 @@ static int nmi_create_files(struct super_block * sb, struct dentry * root)
  
 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_type)
 
 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)