Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: bdbb4be89a2aaff918a9aa6c2cf23660e6ef1a35 https://github.com/WebKit/WebKit/commit/bdbb4be89a2aaff918a9aa6c2cf23660e6ef1a35 Author: Yusuke Suzuki <ysuz...@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@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 <an...@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@safari-7615-branch (44f75343da9e). rdar://107475121 [be894cadcf68a52a] (REGRESSION 256601@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 <rb...@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@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 <rb...@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@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 <csaave...@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@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 _______________________________________________ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes