[webkit-changes] [WebKit/WebKit] bdbb4b: Cherry-pick 259548.47 at safari-7615-branch (0f2c1212...
Claudio Saavedra
noreply at github.com
Fri Mar 31 14:45:45 PDT 2023
Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: bdbb4be89a2aaff918a9aa6c2cf23660e6ef1a35
https://github.com/WebKit/WebKit/commit/bdbb4be89a2aaff918a9aa6c2cf23660e6ef1a35
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-03-31 (Fri, 31 Mar 2023)
Changed paths:
A JSTests/stress/arguments-elimination-should-happen-only-when-stack-slot-is-available-at-replacement-site.js
M Source/JavaScriptCore/dfg/DFGArgumentsEliminationPhase.cpp
Log Message:
-----------
Cherry-pick 259548.47 at safari-7615-branch (0f2c12121b0a). rdar://107474791
[JSC] FTL arguments elimination should ensure that replacement sites can access to original stack slots
https://bugs.webkit.org/show_bug.cgi?id=251640
rdar://99273500
Reviewed by Mark Lam.
FTL arguments elimination does analysis and attempts to eliminate arguments allocation if it is not escaped.
We emit stack access at `arguments[0]` site for example, and remove `arguments` allocations.
But important thing is that stack slots used for the `arguments` need to be available at `arguments[0]` access site.
Since we are using stack slots for different purpose when inlining different functions, it is possible that the given
stack slot is no longer available when using `arguments[0]`. For example,
function a() { return arguments; }
function b() { do-something }
var arg = a()
b();
arg[0]; // If both "a" and "b" are inlined, stack slots used for inlined "a" can be used for the other purpose for "b"
// As a result, it is possible that the slot is not available at `arg[0]` access point.
We were doing stack slot interference analysis to avoid the above problem[1]. However, it was not complete solution since it is only
checking block-local status. So if we have branch between a() and arg[0], this analysis didn't work. Attached test
"arguments-elimination-should-happen-only-when-stack-slot-is-available-at-replacement-site.js" is literally doing this.
function empty() {}
function bar2(...a0) {
return a0;
}
function foo() {
let xs = bar2(undefined);
'' == 1 && 0;
return empty(...xs, undefined);
}
Between bar2 and `...xs` site, we have branch due to &&. And at "...xs" site, the stack slot were no longer available.
In this patch, we replace our existing interference analysis with the revised fix. We use OSR availability which can describe the
state of each stack slot. For all arguments, initially, it is flushed state with a node. Then, when slot gets unavailable or overridden,
we can see the availability change, which no longer points at the same node.
We first do this OSR availability analysis and capture availability map of each candidates. And then, we analyze whether replacement sites
are still seeing the same availability for arguments. And if it becomes different, we remove the candidate from optimization target. This change
simplifies our analysis significantly, and make it procedure global (previous one was block local).
[1]: https://commits.webkit.org/212536@main
* JSTests/stress/arguments-elimination-should-happen-only-when-stack-slot-is-available-at-replacement-site.js: Added.
(empty):
(bar2):
(foo):
(main):
* Source/JavaScriptCore/dfg/DFGArgumentsEliminationPhase.cpp:
Canonical link: https://commits.webkit.org/259548.47@safari-7615-branch
Canonical link: https://commits.webkit.org/262442@main
Commit: 8e4a125888c6042c3d36639e96653123edb30163
https://github.com/WebKit/WebKit/commit/8e4a125888c6042c3d36639e96653123edb30163
Author: Antti Koivisto <antti at apple.com>
Date: 2023-03-31 (Fri, 31 Mar 2023)
Changed paths:
A LayoutTests/fast/css/display-contents-slot-to-none-expected.txt
A LayoutTests/fast/css/display-contents-slot-to-none.html
M Source/WebCore/style/StyleTreeResolver.cpp
Log Message:
-----------
Cherry-pick 259548.51 at safari-7615-branch (44f75343da9e). rdar://107475121
[be894cadcf68a52a] (REGRESSION 256601 at main) ASAN_SEGV | WebCore::RenderObject::pushOntoGeometryMap; WebCore::RenderInline::pushMappingToContainer;
https://bugs.webkit.org/show_bug.cgi?id=251788
rdar://104793275
Reviewed by Alan Baradlay.
* LayoutTests/fast/css/display-contents-slot-to-none-expected.txt: Added.
* LayoutTests/fast/css/display-contents-slot-to-none.html: Added.
* Source/WebCore/style/StyleTreeResolver.cpp:
(WebCore::Style::affectsRenderedSubtree):
We may have had display:contents before and a rendered subtree may still be affected.
Canonical link: https://commits.webkit.org/259548.51@safari-7615-branch
Canonical link: https://commits.webkit.org/262443@main
Commit: ea15ace73a2e2643dc73085a137791fb80f4339a
https://github.com/WebKit/WebKit/commit/ea15ace73a2e2643dc73085a137791fb80f4339a
Author: Rob Buis <rbuis at igalia.com>
Date: 2023-03-31 (Fri, 31 Mar 2023)
Changed paths:
A LayoutTests/fast/multicol/nested-columns-out-of-flow-crash-expected.txt
A LayoutTests/fast/multicol/nested-columns-out-of-flow-crash.html
M Source/WebCore/rendering/RenderObject.cpp
M Source/WebCore/rendering/RenderObject.h
Log Message:
-----------
Cherry-pick 256843.7 at webkit-2022.12-embargoed (3b92d70ba3ea). rdar://107475202
Do not skip fragmented flow thread descendents
https://bugs.webkit.org/show_bug.cgi?id=245374
rdar://98438399
Reviewed by Alan Baradlay.
Do not skip fragmented flow thread descendents in initializeFragmentedFlowStateOnInsertion
since its children may have a different state based on the inserted fragmented
flow thread. When a fragmented flow thread is removed there is no effect on the inner
fragmented flow threads so that behaviour is unchenged.
* LayoutTests/fast/multicol/nested-columns-out-of-flow-crash-expected.txt: Added.
* LayoutTests/fast/multicol/nested-columns-out-of-flow-crash.html: Added.
* Source/WebCore/rendering/RenderObject.cpp:
(WebCore::RenderObject::setFragmentedFlowStateIncludingDescendants):
(WebCore::RenderObject::initializeFragmentedFlowStateOnInsertion):
* Source/WebCore/rendering/RenderObject.h:
Canonical link: https://commits.webkit.org/256843.7@webkit-2022.12-embargoed
Canonical link: https://commits.webkit.org/262444@main
Commit: fa3e94b523cdb209d4db2980a7a92dfeb7cf8707
https://github.com/WebKit/WebKit/commit/fa3e94b523cdb209d4db2980a7a92dfeb7cf8707
Author: Rob Buis <rbuis at igalia.com>
Date: 2023-03-31 (Fri, 31 Mar 2023)
Changed paths:
A LayoutTests/fast/layers/normal-flow-dialog-remove-layer-crash-expected.html
A LayoutTests/fast/layers/normal-flow-dialog-remove-layer-crash.html
M Source/WebCore/rendering/RenderLayer.cpp
Log Message:
-----------
Cherry-pick 256843.8 at webkit-2022.12-embargoed (fe2f16c1dabe). rdar://107475239
Recalculate normal flow value in RenderLayer::establishesTopLayerDidChange
https://bugs.webkit.org/show_bug.cgi?id=251013
Reviewed by Tim Nguyen.
In RenderLayer::rebuildZOrderLists the RenderView layer makes sure the layers for dialogs/top-level elements are appended after
everything else in the positive z-order list. When removing the dialog layer, dirtyPaintOrderListsOnChildChange will be called
and since it is not a normal only flow everything will be handled correctly through dirtyStackingContextZOrderLists.
In the test case the behaviour is the same until dirtyPaintOrderListsOnChildChange is called on the dialog layer removal. Now that
layer to be removed *is* a normal only flow (the element is no longer positioned and has non visible overflow, see
RenderLayer::shouldBeNormalFlowOnly). This means the positive z-order list is unchanged and the deleted layer still part of it.
When the test cleanup code does a final repaint, the RenderView positive z-order list is processed as normal and when trying to
access the deleted layer the UAF happens.
To fix this, make sure the normal flow value is correct when adding the layer in RenderLayer::establishesTopLayerDidChange.
* LayoutTests/fast/layers/normal-flow-dialog-remove-layer-crash-expected.html: Added.
* LayoutTests/fast/layers/normal-flow-dialog-remove-layer-crash.html: Added.
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::establishesTopLayerDidChange):
Canonical link: https://commits.webkit.org/256843.8@webkit-2022.12-embargoed
Canonical link: https://commits.webkit.org/262445@main
Commit: 55616cb231b6806084e5b17f82cd9612ab260394
https://github.com/WebKit/WebKit/commit/55616cb231b6806084e5b17f82cd9612ab260394
Author: Claudio Saavedra <csaavedra at igalia.com>
Date: 2023-03-31 (Fri, 31 Mar 2023)
Changed paths:
A LayoutTests/fast/css/content/content-on-focus-change-expected.txt
A LayoutTests/fast/css/content/content-on-focus-change.html
Log Message:
-----------
Cherry-pick 256843.9 at webkit-2022.12-embargoed (4c3dcd480f7e). rdar://107475307
Test display contents change on focus change
https://bugs.webkit.org/show_bug.cgi?id=251014
Reviewed by Tim Nguyen.
* LayoutTests/fast/css/content/content-on-focus-change-expected.txt: Added.
* LayoutTests/fast/css/content/content-on-focus-change.html: Added.
Canonical link: https://commits.webkit.org/256843.9@webkit-2022.12-embargoed
Canonical link: https://commits.webkit.org/262446@main
Compare: https://github.com/WebKit/WebKit/compare/e3babff08eae...55616cb231b6
More information about the webkit-changes
mailing list