Reproduces locally (with tsan), and bisects to ac2ac7b771c7d5838b4e2e35523bf38d215ac926 (Enable SharedArrayBuffer feature by default. (Reland)).

Ben, can you take a look at this data race?

This race looks scary to me, and it's in there for quite some while, so I am restricting view to the security team and raising priority.
After investigation, please either mark as Bug-Security, or remove the view restriction.

This looks like an "expected" race to me. It appears to be only racing on the backing store memory. simple-worker-1.js has a non-atomic write, and simple-worker-2.js has a non-atomic read when the `memory` is postMessage'd.

We should make sure that this doesn't fire the thread sanitizer, though. I'll take a look.

Agreed. Removing view restriction. Thanks for investigating!

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/181c03e9cc7f6b8e2391bfcf4e432556a05a9245

commit 181c03e9cc7f6b8e2391bfcf4e432556a05a9245
Author: Ben Smith <binji@chromium.org>
Date: Fri Sep 08 18:35:17 2017

Add TSAN annotations for TypedArray accesses

TSAN finds data races in generated JavaScript code that use
access the SharedArrayBuffer backing store racily. These are races, but
they are OK in the sense that the JavaScript memory model allows for the
potential bad behavior they could introduce (e.g. potentially tearing
reads). Relaxed atomics could be used here instead, but that could
introduce performance regressions.

This change adds TSAN annotations to the TypedArray reads/writes to
prevent TSAN from warning about them.

Bug:  chromium:722871 
Change-Id: I0776475f02a352b678ade7d32ed6bd4a6be98c36
Reviewed-on: https://chromium-review.googlesource.com/656509
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47929}
[modify] https://crrev.com/181c03e9cc7f6b8e2391bfcf4e432556a05a9245/BUILD.gn
[add] https://crrev.com/181c03e9cc7f6b8e2391bfcf4e432556a05a9245/src/base/tsan.h
[modify] https://crrev.com/181c03e9cc7f6b8e2391bfcf4e432556a05a9245/src/objects-inl.h
[modify] https://crrev.com/181c03e9cc7f6b8e2391bfcf4e432556a05a9245/src/v8.gyp
[add] https://crrev.com/181c03e9cc7f6b8e2391bfcf4e432556a05a9245/test/mjsunit/regress/regress-crbug-722871.js

ClusterFuzz has detected this issue as fixed in range 500732:500754.

Detailed report: https://clusterfuzz.com/testcase?key=5367119817736192

Fuzzer: inferno_layout_test_unmodified
Job Type: linux_tsan_chrome_mp
Platform Id: linux

Crash Type: Data race READ 4
Crash Address: 0x7b4c000303c4
Crash State:
  v8::internal::ElementsAccessorBase<v8::internal::TypedElementsAccessor<
  v8::internal::LookupIterator::FetchValue
  v8::internal::LookupIterator::GetDataValue
  
Sanitizer: thread (TSAN)

Fixed: https://clusterfuzz.com/revisions?job=linux_tsan_chrome_mp&range=500732:500754

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5367119817736192

See https://github.com/google/clusterfuzz-tools for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 5367119817736192 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.