OSDN Git Service

xen: use stronger barrier after unlocking lock
authorYang Xiaowei <xiaowei.yang@intel.com>
Wed, 9 Sep 2009 19:44:52 +0000 (12:44 -0700)
committerJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Wed, 9 Sep 2009 23:38:44 +0000 (16:38 -0700)
We need to have a stronger barrier between releasing the lock and
checking for any waiting spinners.  A compiler barrier is not sufficient
because the CPU's ordering rules do not prevent the read xl->spinners
from happening before the unlock assignment, as they are different
memory locations.

We need to have an explicit barrier to enforce the write-read ordering
to different memory locations.

Because of it, I can't bring up > 4 HVM guests on one SMP machine.

[ Code and commit comments expanded -J ]

[ Impact: avoid deadlock when using Xen PV spinlocks ]

Signed-off-by: Yang Xiaowei <xiaowei.yang@intel.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
arch/x86/xen/spinlock.c

index 2f91e56..36a5141 100644 (file)
@@ -326,8 +326,13 @@ static void xen_spin_unlock(struct raw_spinlock *lock)
        smp_wmb();              /* make sure no writes get moved after unlock */
        xl->lock = 0;           /* release lock */
 
-       /* make sure unlock happens before kick */
-       barrier();
+       /*
+        * Make sure unlock happens before checking for waiting
+        * spinners.  We need a strong barrier to enforce the
+        * write-read ordering to different memory locations, as the
+        * CPU makes no implied guarantees about their ordering.
+        */
+       mb();
 
        if (unlikely(xl->spinners))
                xen_spin_unlock_slow(xl);