From: Ingo Molnar 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 --- 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) _