From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: [PATCH 1 of 3] xen: Fix schedule's grabbing of the schedule lock Date: Thu, 5 Apr 2012 12:54:52 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xensource.com Cc: george.dunlap@eu.citrix.com List-Id: xen-devel@lists.xenproject.org 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 diff -r 197e09bf0322 -r fd0d2fd2824b xen/common/schedule.c --- a/xen/common/schedule.c Wed Apr 04 11:29:43 2012 +0100 +++ b/xen/common/schedule.c Thu Apr 05 12:20:04 2012 +0100 @@ -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);