x86: Restore proper vector locking during cpu hotplug

Having cpu_online_map change during assign_irq_vector can result
in some really nasty and weird things happening.  The one that
bit me last time was accessing non existent per cpu memory for non
existent cpus.

This locking was removed in a sloppy x86_64 and x86_32 merge patch.

Guys can we please try and avoid subtly breaking x86 when we are
merging files together?

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>

1 files changed, 9 insertions, 3 deletions

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 332512767f4f..da10f07fc59c 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -326,12 +326,16 @@ static void __cpuinit start_secondary(void *unused)
          * for which cpus receive the IPI. Holding this
          * lock helps us to not include this cpu in a currently in progress
          * smp_call_function().
+         *
+         * We need to hold vector_lock so there the set of online cpus
+         * does not change while we are assigning vectors to cpus.  Holding
+         * this lock ensures we don't half assign or remove an irq from a cpu.
          */
         ipi_call_lock_irq();
-#ifdef CONFIG_X86_IO_APIC
-        setup_vector_irq(smp_processor_id());
-#endif
+        lock_vector_lock();
+        __setup_vector_irq(smp_processor_id());
         cpu_set(smp_processor_id(), cpu_online_map);
+        unlock_vector_lock();
         ipi_call_unlock_irq();
         per_cpu(cpu_state, smp_processor_id()) = CPU_ONLINE;
 
@@ -1336,7 +1340,9 @@ int __cpu_disable(void)
         remove_siblinginfo(cpu);
 
         /* It's now safe to remove this processor from the online map */
+        lock_vector_lock();
         remove_cpu_from_maps(cpu);
+        unlock_vector_lock();
         fixup_irqs(cpu_online_map);
         return 0;
 }