[SERVER-58403] Serialize concurrent accesses to `OperationContext::_comment` Created: 09/Jul/21  Updated: 29/Oct/23  Resolved: 27/Jul/21

Status: Closed
Project: Core Server
Component/s: Internal Code
Affects Version/s: None
Fix Version/s: 5.1.0-rc0

Type: Bug Priority: Major - P3
Reporter: Amirsaman Memaripour Assignee: Jennifer Peshansky (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Problem/Incident
is caused by SERVER-29794 Adding a comment to all commands Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Query Execution 2021-07-26, QE 2021-08-09
Participants:
Linked BF Score: 138

 Description   

SERVER-29794 added _comment as a new member of OperationContext, and exposed setComment()/getComment() to set/get the value of the new field.

Accessing _comment, however, is not thread-safe, and to ensure thread-safety:

  • The client lock must be acquired before calling into setComment().
  • The client lock must be acquired to getComment() from any thread that does not own the client associated with the operation (i.e., Client::getCurrent() != opCtx->getClient()).

The common practice is to use the client lock to serialize concurrent accesses to OperationContext fields that are not thread-safe. We currently do so to access _comment when preparing the currentOp output (see here).



 Comments   
Comment by Vivian Ge (Inactive) [ 06/Oct/21 ]

Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you!

Comment by Githook User [ 27/Jul/21 ]

Author:

{'name': 'Jennifer Peshansky', 'email': 'jennifer.peshansky@mongodb.com', 'username': 'jenniferpeshansky'}

Message: SERVER-58403 Serialize concurrent accesses to OperationContext::_comment
Branch: master
https://github.com/mongodb/mongo/commit/81dd7b36b863e57c0cbba1032a550bb55f353390

Comment by Mickey Winters [ 16/Jul/21 ]

This is infact the same _comment as in BF-21476, and in that BF there is potentially parallel access of _comment. However I feel like if this was the cause of BF-21476 then the test would have failed because the comment was clobbered or half written, not because trying to read the comment was slow which is why it really failed. unless there is some strlen or strcmp in the shell code that kept reading because a null terminator wasn't copied yet

Comment by Ethan Zhang (Inactive) [ 15/Jul/21 ]

Assigning this to mickey.winters to see if it is related to BF-21476

Generated at Thu Feb 08 05:44:25 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.