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.
git-svn-id: http://svn.webkit.org/repository/webkit/trunk@231148 268f45cc-cd09-0410-ab3c-d52691b4dbfc
diff --git a/Source/WTF/ChangeLog b/Source/WTF/ChangeLog
index a05d6d4..666e6df 100644
--- a/Source/WTF/ChangeLog
+++ b/Source/WTF/ChangeLog
@@ -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
diff --git a/Source/WTF/benchmarks/ToyLocks.h b/Source/WTF/benchmarks/ToyLocks.h
index bacad2e..03f75a1 100644
--- a/Source/WTF/benchmarks/ToyLocks.h
+++ b/Source/WTF/benchmarks/ToyLocks.h
@@ -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>)
diff --git a/Source/WTF/wtf/WordLock.cpp b/Source/WTF/wtf/WordLock.cpp
index 0189e58..cfe0905 100644
--- a/Source/WTF/wtf/WordLock.cpp
+++ b/Source/WTF/wtf/WordLock.cpp
@@ -254,12 +254,15 @@
// 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!
}
