Branch: refs/heads/webkitglib/2.54
Home: https://github.com/WebKit/WebKit
Commit: d316b0131d5a0d6f0eb453f0ea380d37bae7b54e
https://github.com/WebKit/WebKit/commit/d316b0131d5a0d6f0eb453f0ea380d37bae7b54e
Author: Dan Hecht <[email protected]>
Date: 2026-09-07 (Mon, 07 Sep 2026)
Changed paths:
A JSTests/stress/operation-polymorphic-call-host-call-ic-reset.js
M Source/JavaScriptCore/bytecode/RepatchInlines.h
M Source/JavaScriptCore/jit/JITOperations.cpp
M Source/JavaScriptCore/llint/LLIntSlowPaths.cpp
Log Message:
-----------
Cherry-pick [email protected] (09ca909b6a83).
https://bugs.webkit.org/show_bug.cgi?id=317142
[JSC] Do not attempt to link a CallLinkInfo after handleHostCall
https://bugs.webkit.org/show_bug.cgi?id=317142
rdar://178282225
Reviewed by Yusuke Suzuki.
handleHostCall performs the host call which may execute JS that
fires a watchpoint invalidating the passed CallLinkInfo. So,
it's not safe to modify *CallLinkInfo after the host call.
So, make the callers of virtualForWithFunction skip the
linkPolymorphicCall call in this case. This aligns the behavior
of operationPolymorphicCall / llint_polymorphic_call with linkFor.
However, to avoid the InternalFunction case potentially getting
stuck in the polymorphic mode slow path, return the JSCell in this case.
This is a slight change in behavior: before this change,
InternalFunction would have caused the CallLinkInfo to downgrade
to virtual mode. With this change, it can remain in polymorphic
mode. This also aligns with linkFor behavior.
Test: JSTests/stress/operation-polymorphic-call-host-call-ic-reset.js
* JSTests/stress/operation-polymorphic-call-host-call-ic-reset.js: Added.
(g2):
(g3):
(getP):
(evil.new.Proxy):
(evil.new.Proxy.apply):
* Source/JavaScriptCore/bytecode/RepatchInlines.h:
(JSC::virtualForWithFunction):
* Source/JavaScriptCore/jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
* Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:
(JSC::LLInt::llint_polymorphic_call):
Identifier: [email protected]
Canonical link: https://commits.webkit.org/317695.204@webkitglib/2.54
Commit: 2bbb93aa5d88e18304cb746d71e436ad34a41e77
https://github.com/WebKit/WebKit/commit/2bbb93aa5d88e18304cb746d71e436ad34a41e77
Author: Youenn Fablet <[email protected]>
Date: 2026-09-07 (Mon, 07 Sep 2026)
Changed paths:
A
LayoutTests/http/wpt/cache-storage/cache-put-opaque-response-race-expected.txt
A LayoutTests/http/wpt/cache-storage/cache-put-opaque-response-race.html
M Source/WebCore/Modules/cache/CacheStorageConnection.cpp
M Source/WebCore/Modules/cache/CacheStorageConnection.h
Log Message:
-----------
Cherry-pick [email protected] (4c69ed8ad988).
https://bugs.webkit.org/show_bug.cgi?id=317270
Unsynchronized cross-thread access to m_opaqueResponseToSizeWithPaddingMap
in CacheStorageConnection::computeRecordBodySize
rdar://177953125
Reviewed by Chris Dumez.
We add a lock and the related lock assertions to prevent unlocked access to
the map.
Given the potential locking that may happen for form data size computation,
we make sure to compute the response real size outside of the lock.
Test: http/wpt/cache-storage/cache-put-opaque-response-race.html
*
LayoutTests/http/wpt/cache-storage/cache-put-opaque-response-race-expected.txt:
Added.
* LayoutTests/http/wpt/cache-storage/cache-put-opaque-response-race.html:
Added.
* Source/WebCore/Modules/cache/CacheStorageConnection.cpp:
(WebCore::CacheStorageConnection::computeRecordBodySize):
* Source/WebCore/Modules/cache/CacheStorageConnection.h:
Identifier: [email protected]
Canonical link: https://commits.webkit.org/317695.205@webkitglib/2.54
Commit: 4f518a958b8993e21dafe206f6f824a3173fc4ea
https://github.com/WebKit/WebKit/commit/4f518a958b8993e21dafe206f6f824a3173fc4ea
Author: Kimmo Kinnunen <[email protected]>
Date: 2026-09-07 (Mon, 07 Sep 2026)
Changed paths:
A
LayoutTests/ipc/set-fill-pattern-image-buffer-cross-backend-race-expected.txt
A LayoutTests/ipc/set-fill-pattern-image-buffer-cross-backend-race.html
M Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp
Log Message:
-----------
Cherry-pick [email protected] (d5c5da3f748b).
https://bugs.webkit.org/show_bug.cgi?id=317295
SerializedImageBuffer leaks cross-RemoteRenderingBackend data through
GraphicsContext
https://bugs.webkit.org/show_bug.cgi?id=317295
rdar://175520296
Reviewed by Dan Glastonbury.
ImageBuffer context state might leak non-thread-safe
cross-RemoteRenderingBackend instances through GraphicsContext state.
Release the GraphicsContext when transfering the ImageBuffer to
different RRB.
*
LayoutTests/ipc/set-fill-pattern-image-buffer-cross-backend-race-expected.txt:
Added.
* LayoutTests/ipc/set-fill-pattern-image-buffer-cross-backend-race.html:
Added.
* Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp:
(WebKit::RemoteRenderingBackend::moveToSerializedBuffer):
Identifier: [email protected]
Canonical link: https://commits.webkit.org/317695.206@webkitglib/2.54
Compare: https://github.com/WebKit/WebKit/compare/e0bd97cd00e1...4f518a958b89
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
