Fixed a very unlikely race condition in WTF::WordLock
authorggaren@apple.com <ggaren@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Sun, 29 Apr 2018 15:23:52 +0000 (15:23 +0000)
committerggaren@apple.com <ggaren@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Sun, 29 Apr 2018 15:23:52 +0000 (15:23 +0000)
https://bugs.webkit.org/show_bug.cgi?id=185117

Reviewed by Saam Barati.

The race goes like this:

Thread L is in lockSlowCase() and thread U is in unlockSlowCase();

- U acquires queueHead->parkingLock.
- U sets queueHead->shouldPark = false
- U releases queueHead->parkingLock.
- L spuriously wakes up from queueHead->parkingLock.wait()
- L acquires queueHead->parkingLock.
- L notices that queueHead->shouldPark = false, and acquires the WordLock
- L finishes all its work and exits, freeing queueHead
- U notifies queueHead->parkingLock (after free) and crashes or deadlocks

These conditions are currently so unlikely that I don't know how to test
them. I noticed this race because I changed WordLock's allocation pattern
to allow queueHead to be freed more often, and I crashed / deadlocked 100%.

Shout out to <http://en.cppreference.com/w/cpp/thread/condition_variable/notify_one>
for explaining this.

* benchmarks/ToyLocks.h: Fixed build.

* wtf/WordLock.cpp:
(WTF::WordLock::unlockSlow): Hold the lock a little longer to avoid
this race.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@231148 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Source/WTF/ChangeLog
Source/WTF/benchmarks/ToyLocks.h
Source/WTF/wtf/WordLock.cpp

index a05d6d4..666e6df 100644 (file)
@@ -1,3 +1,36 @@
+2018-04-28  Geoffrey Garen  <ggaren@apple.com>
+
+        Fixed a very unlikely race condition in WTF::WordLock
+        https://bugs.webkit.org/show_bug.cgi?id=185117
+
+        Reviewed by Saam Barati.
+
+        The race goes like this:
+
+        Thread L is in lockSlowCase() and thread U is in unlockSlowCase();
+
+        - U acquires queueHead->parkingLock.
+        - U sets queueHead->shouldPark = false
+        - U releases queueHead->parkingLock.
+        - L spuriously wakes up from queueHead->parkingLock.wait()
+        - L acquires queueHead->parkingLock.
+        - L notices that queueHead->shouldPark = false, and acquires the WordLock
+        - L finishes all its work and exits, freeing queueHead
+        - U notifies queueHead->parkingLock (after free) and crashes or deadlocks
+
+        These conditions are currently so unlikely that I don't know how to test
+        them. I noticed this race because I changed WordLock's allocation pattern
+        to allow queueHead to be freed more often, and I crashed / deadlocked 100%.
+
+        Shout out to <http://en.cppreference.com/w/cpp/thread/condition_variable/notify_one>
+        for explaining this.
+
+        * benchmarks/ToyLocks.h: Fixed build.
+
+        * wtf/WordLock.cpp:
+        (WTF::WordLock::unlockSlow): Hold the lock a little longer to avoid
+        this race.
+
 2018-04-27  David Kilzer  <ddkilzer@apple.com>
 
         Add logging when SpringBoard enables WebThread
index bacad2e..03f75a1 100644 (file)
@@ -31,6 +31,7 @@
 #include <wtf/Atomics.h>
 #include <wtf/Lock.h>
 #include <wtf/ParkingLot.h>
+#include <wtf/Threading.h>
 #include <wtf/WordLock.h>
 
 #if __has_include(<os/lock.h>)
index 0189e58..cfe0905 100644 (file)
@@ -254,12 +254,15 @@ NEVER_INLINE void WordLock::unlockSlow()
     // We do this carefully because this may run either before or during the parkingLock critical
     // section in lockSlow().
     {
+        // Be sure to hold the lock across our call to notify_one() because a spurious wakeup could
+        // cause the thread at the head of the queue to exit and delete queueHead.
         std::lock_guard<std::mutex> locker(queueHead->parkingLock);
         queueHead->shouldPark = false;
+
+        // Doesn't matter if we notify_all() or notify_one() here since the only thread that could be
+        // waiting is queueHead.
+        queueHead->parkingCondition.notify_one();
     }
-    // Doesn't matter if we notify_all() or notify_one() here since the only thread that could be
-    // waiting is queueHead.
-    queueHead->parkingCondition.notify_one();
 
     // The old queue head can now contend for the lock again. We're done!
 }