Skip to content

V
V8
Switch branch/tag
  1. 07 Dec, 2021 1 commit
  3. 06 Dec, 2021 1 commit
  5. 30 Nov, 2021 2 commits
  7. 29 Nov, 2021 1 commit
  9. 26 Oct, 2021 1 commit
  11. 25 Oct, 2021 1 commit
  13. 30 Sep, 2021 1 commit
  15. 21 Jul, 2021 1 commit
    • Michael Lippautz's avatar
      cppgc: Allow CrossThreadPersistent to access poisoned memory from GC · c58862c3
      Michael Lippautz authored 
      Allow CrossThreadPersistent and its weak form to access ASAN poisoned
memory from the GC entry points.

In general, payloads of to-be-finalized objects are poisoned until the
finalizer actually runs to avoid accidentally touching that payload.

In the case of cross-thread handles, these may need to be cleared by a
different thread before the finalizer actually runs. In order to clear
those references, the slot needs to be unpoisoned.

This is issue is ASAN-only and does not affect production or other
debug builds.

Bug: chromium:1230599, chromium:1056170
Change-Id: If4d0808953047319b02653821abbb5c638084dc5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040845
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75846}
      c58862c3
  17. 09 Mar, 2021 1 commit
  19. 08 Mar, 2021 1 commit
  21. 24 Feb, 2021 2 commits
    • Omer Katz's avatar
      cppgc: Add missing guard for PersistentNode allocation. · d98b12d3
      Omer Katz authored 
      Two threads might get the same PersistentNode because the
BasicCrossThreadPersistent ctor wasn't taking a lock. Then if one thread
frees the node and the other initalizes it or updates its owner, we get
some random object in our free list of PersistentNodes.

I debug a crash in Assign(Unsafe) and Clear where the PersistentNode
seemed to be allocated on stack. Empirically, adding this guard resolved
it. I can't confirm in the code that the scenario above is what was
happening.

Drive-by: adding a few DCHECKs.

Bug: chromium:1056170
Change-Id: I37d8ed5bb942a124c98d7524b7f04fe8ccb2aefd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718144
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73023}
      d98b12d3
    • Omer Katz's avatar
      cppgc: Check AssignUnsafe use cases · e18591df
      Omer Katz authored 
      Assert that the lock is help whenever AssignUnsafe is called.
LazyMutex::AssertHeld resolves to a DCHECK so this should not
regress production performance (other than the call itself
that might not be inlined).

Bug: chromium:1056170
Change-Id: Ic2005d180e6960c24dff7743aa3e0d5e57a63d80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716286Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73000}
      e18591df
  23. 19 Jan, 2021 1 commit
  25. 19 Oct, 2020 1 commit
  27. 09 Oct, 2020 1 commit
    • Michael Lippautz's avatar
      Migrate CrossThreadPersistent · 4569ffae
      Michael Lippautz authored 
      Adds a cross-thread reference for strongly and weakly retaining
objects on a thread other than the thread that owns the object.

The intended use of the reference is by setting it up on the
originating thread, holding the object alive from another thread, and
ultimately accessing the object again on the originating thread.

The reference has known caveats:
- It's unsafe to use when the heap may terminate;
- It's unsafe to transitively reach through the graph because of
  compaction;

Change-Id: I84fbdde69a099eb54af5b93c34e2169915b17e64
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436449
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarAnton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70428}
      4569ffae
  29. 19 Jun, 2020 1 commit
    • Michael Lippautz's avatar
      Reland "cppgc: Properly clear (Weak)Peristent and WeakMember pointers" · 8bdce527
      Michael Lippautz authored 
      This is a reland of e0c1a349

The issue was passing SentinelPointer (== +1) through T*.

The fix is disabling cfi unrelated cast diagnostic for the bottlenecks
(Get()). This means that nullptr is treated the same as
kSentinelPointer.

The alternative would be a DCHECK that Get() does not return
kSentinelPointer and adjusting all Member and Persistent logic that
uses Get() to work on void*. This is quite intrusive as it involves
Swap(), heterogeneous assignments, comparisons, etc.

Original change's description:
> cppgc: Properly clear (Weak)Peristent and WeakMember pointers
>
> The CL addresses two issues with (Weak)Persistent and WeakMember:
> 1. (Weak)Persistent pointers are cleared on heap teardown. Before this
>    CL the pointers would contain stale values which could lead to UAF.
> 2. WeakPersistent and WeakMember are cleared using a combination of
>    internal clearing methods and mutable fields which avoids the use
>    of const_cast<>.
>
> Bug: chromium:1056170
> Change-Id: Ibf2b0f0856771b4f6906608cde13a6d43ebf81f3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2248190
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68394}

Bug: chromium:1056170
Change-Id: I3d74b43464c2973df1956f51b1419d755dd9f519
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250240Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarAnton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68426}
      8bdce527
  31. 17 Jun, 2020 2 commits
  33. 27 Apr, 2020 3 commits
  35. 21 Apr, 2020 1 commit
  37. 15 Apr, 2020 1 commit