Predator and CL did not provide any possible suspects.
Using Code Search for the file, "MutexLock.hpp" assigning to concern owner.

Suspecting Commit#
https://swiftshader.googlesource.com/SwiftShader.git/+/35e0ba7753cab88905b428b65577669620798507

@capn -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

The ClusterFuzz report was created back in April, and we no longer even use BackoffLock on Linux: https://swiftshader-review.googlesource.com/8648. So I'm puzzled how this could still reproduce on a recent revision (I've checked that this piece of code hasn't changed since).

So I'm going to assume this is either a ClusterFuzz hiccup or a build from a branch with the older code. Even in the latter case this is entirely benign because the BackoffLock implementation inherently has data fields that may be altered more than once before all threads read it.

ClusterFuzz has detected this issue as fixed in range 477291:477303.

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

Fuzzer: inferno_layout_test_unmodified
Job Type: linux_tsan_chrome_mp
Platform Id: linux

Crash Type: Data race READ 4
Crash Address: 0x7b4000002448
Crash State:
  sw::BackoffLock::lock
  sw::Resource::lock
  sw::Surface::lockInternal
  
Sanitizer: thread (TSAN)

Fixed: https://clusterfuzz.com/revisions?job=linux_tsan_chrome_mp&range=477291:477303

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


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.