Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: aed1fddc0be21a3eb4e94a231d794898b0360886
https://github.com/WebKit/WebKit/commit/aed1fddc0be21a3eb4e94a231d794898b0360886
Author: Yusuke Suzuki <[email protected]>
Date: 2026-05-29 (Fri, 29 May 2026)
Changed paths:
M Source/JavaScriptCore/runtime/JSLock.cpp
M Source/JavaScriptCore/runtime/JSLock.h
Log Message:
-----------
[JSC] JSLock m_hasOwnerThread has concurrency issue
https://bugs.webkit.org/show_bug.cgi?id=311431
rdar://173797266
Reviewed by Dan Hecht.
JSLock::lock is storing `true` flag to JSLock::m_hasOwnerThread after
store-store-barrier. However loading this is not having a brrier. This
is problemtic since JSLock is keeping two fields in sync: m_hasOwnerThread
and m_ownerThread. But ordering of stores to them and visibility of the
state of them must be strongly controlled, otherwise, random thread
accidentlly think that "we are already taking a lock" while it is not.
In particular, currentThreadIsHoldingLock has a bug that we are loading
these two fields without any barriers. So CPU can freely change the
visibility of the other thread's store to them. We may see a state that
m_hasOwnerThread is true, but m_ownerThread is not stored yet.
This patch fixes this issue by using release-acquire load/store for
m_hasOwnerThread. This ensures the load and store ordering before and
after this variable. So we can guarantee that m_ownerThread is not a
stale state.
* Source/JavaScriptCore/runtime/JSLock.cpp:
* Source/JavaScriptCore/runtime/JSLock.h:
(JSC::JSLock::ownerThread const):
(JSC::JSLock::ownerThreadUID const):
(JSC::JSLock::currentThreadIsHoldingLock):
Originally-landed-as: 305413.611@rapid/safari-7624.2.5.110-branch
(729df7fb2917). rdar://176061322
Canonical link: https://commits.webkit.org/314150@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
