xen: Fix schedule()'s grabbing of the schedule lock

Because the location of the lock can change between the time you read
it and the time you grab it, the per-cpu schedule locks need to check
after lock acquisition that the lock location hasn't changed, and
release and re-try if so.  This change was effected throughout the
source code, but one very important place was apparently missed: in
schedule() itself.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Committed-by: Keir Fraser <keir@xen.org>

diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index a1eeac36eb49f0af6309bf1e31b9106a9297fa11..724e8fa1ab4e144ca1a036cb3f81be8ab9ef0e6b 100644 (file)
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -1075,6 +1075,7 @@ static void schedule(void)
     bool_t                tasklet_work_scheduled = 0;
     struct schedule_data *sd;
     struct task_slice     next_slice;
+    int cpu = smp_processor_id();
 
     ASSERT(!in_atomic());
 
@@ -1099,7 +1100,7 @@ static void schedule(void)
         BUG();
     }
 
-    spin_lock_irq(sd->schedule_lock);
+    pcpu_schedule_lock_irq(cpu);
 
     stop_timer(&sd->s_timer);
     
@@ -1116,7 +1117,7 @@ static void schedule(void)
 
     if ( unlikely(prev == next) )
     {
-        spin_unlock_irq(sd->schedule_lock);
+        pcpu_schedule_unlock_irq(cpu);
         trace_continue_running(next);
         return continue_running(prev);
     }
@@ -1154,7 +1155,7 @@ static void schedule(void)
     ASSERT(!next->is_running);
     next->is_running = 1;
 
-    spin_unlock_irq(sd->schedule_lock);
+    pcpu_schedule_unlock_irq(cpu);
 
     perfc_incr(sched_ctx);