[SERVER-84514] Enforce implicit rules around use of OperationContext on a RemoteCommandRequest Created: 02/Jan/24  Updated: 05/Feb/24

Status: Investigating
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: George Wangensteen Assignee: George Wangensteen
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Service Arch
Sprint: Service Arch 2024-02-05, Service Arch 2024-02-19
Participants:

 Description   

When a RemoteCommandRequest has an OperationContext member, that member is only accessed on the thread that calls scheduleRemoteCommand/NetworkInterface::startCommand. The general historical rule (see this comment) is that the client-thread owning the OperationContext should be the one to call scheduleRemoteCommand, to ensure that the OperationContext is not destroyed before it is read off the RemoteCommandRequest.

Generally, it is not safe to call scheduleRemoteCommand with an RCR with an OperationContext from a different thread, unless there is additional synchronization that ensures the OperationContext isn't destroyed.

We should consider enforcing these rules in code, i.e. by insisting that the thread-local client of the thread calling scheduleRemoteCommand owns the OperationContext, etc.


Generated at Thu Feb 08 06:55:14 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.