ia64/xen-unstable
changeset 6816:3a34bcb7c28b
Fix the logic in vcpu_sleep_sync(): we must wait until
the running flag is cleared *and* the scheduler lock is
released. Not just one or the other.
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
the running flag is cleared *and* the scheduler lock is
released. Not just one or the other.
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
author | kaf24@firebug.cl.cam.ac.uk |
---|---|
date | Tue Sep 13 19:09:44 2005 +0000 (2005-09-13) |
parents | fe5b84a24d43 |
children | feff6bf0417e |
files | xen/common/schedule.c |
line diff
1.1 --- a/xen/common/schedule.c Tue Sep 13 10:03:04 2005 -0800 1.2 +++ b/xen/common/schedule.c Tue Sep 13 19:09:44 2005 +0000 1.3 @@ -211,11 +211,12 @@ void vcpu_sleep_sync(struct vcpu *v) 1.4 1.5 /* 1.6 * We can be sure that the VCPU is finally descheduled after the running 1.7 - * flag is cleared and the scheduler lock is released. 1.8 + * flag is cleared and the scheduler lock is released. We also check that 1.9 + * the domain continues to be unrunnable, in case someone else wakes it. 1.10 */ 1.11 - while ( test_bit(_VCPUF_running, &v->vcpu_flags) 1.12 - && !domain_runnable(v) 1.13 - && spin_is_locked(&schedule_data[v->processor].schedule_lock) ) 1.14 + while ( !domain_runnable(v) && 1.15 + (test_bit(_VCPUF_running, &v->vcpu_flags) || 1.16 + spin_is_locked(&schedule_data[v->processor].schedule_lock)) ) 1.17 cpu_relax(); 1.18 1.19 sync_vcpu_execstate(v);