From: George Dunlap <george.dunlap@eu.citrix.com>
Date: Tue, 10 Apr 2012 09:41:30 +0000 (+0100)
Subject: xen: Fix schedule()'s grabbing of the schedule lock
X-Git-Tag: 4.2.0-rc1~520
X-Git-Url: http://xenbits.xensource.com/gitweb?a=commitdiff_plain;h=4cee6a3812e9e81532f89b5be15d549faf49fffd;p=xen.git

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 a1eeac36eb..724e8fa1ab 100644
--- 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);