-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Internal Code
-
Fully Compatible
-
ALL
-
v5.0
-
Service Arch 2021-06-14, Service Arch 2021-06-28
-
144
-
4
We create a new opCtx to serve each client request (see here). This opCtx is later destroyed in the tail of a future-continuation constructed in ServiceStateMachine::Impl::startNewLoop (see here). The destruction of opCtx, however, may run on a thread other than the one that has the Client object attached, causing read-after-free race conditions.
Future<void> ServiceStateMachine::Impl::processMessage() {
...
_opCtx = Client::getCurrent()->makeOperationContext();
...
}
.getAsync([this](Status status) { // We may or may not have an operation context, but it should definitely be gone now. _opCtx.reset(); ... });
Similarly, the opCtx used to run a command is killed after returning from handleRequest (see here). This may also run on a thread other than the one holding the client lock, resulting in data races. We should ensure the operation is only killed on a thread that owns its corresponding client object.
Acceptance criteria: ensure the opCtx is always killed/destructed while having its Client attached to the current thread (e.g., by binding the ClientStrand). The performance impact of the changes must also be evaluated (using sys-perf), as the change is on the critical path of command execution.
- is related to
-
SERVER-50141 ServiceStateMachineTest needs to be rewritten
- Closed
-
SERVER-51015 Rewrite ServiceExecutor interface to be Client aware
- Closed
- related to
-
SERVER-53993 Attach client strand before releasing the opCtx in AsyncCommandExecution tests
- Closed