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)
_