The thread sanitizer build variant has caught a couple of data race scenarios that involve the Locker::getLockerInfo() method. So far, these data races involve diagnostic commands such as currentOp or FTDC.

1. The first data race in LockerImpl::getLockerInfo() involves iterating over the _requests map and accessing the lock requests mode here. The problem here is that we insert the lock request into the map here with mode MODE_NONE. Now, this lock request is accessible to the map iterator in LockerImpl::getLockerInfo(), but later on, as we're still acquiring the lock we change the lock requests mode here without any synchronization.
2. The second data race involving LockerImpl::getLockerInfo() involves copying the locker info stats here. While the copy is happening via this method, a new global lock acquisition can come in and increment the statistics, calling this. This is problematic because there is no synchronization between incrementing the counter and copying its value.

Based on these findings, it would be wise to audit LockerImpl::getLockerInfo() for any other data races the thread sanitizer may not have discovered yet.