[SERVER-61934] Race between creating new opCtx and killing opCtx's before switching out the storage engine Created: 06/Dec/21  Updated: 29/Oct/23  Resolved: 10/Jan/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 5.3.0, 5.2.0-rc5

Type: Bug Priority: Blocker - P1
Reporter: Samyukta Lanka Assignee: Samyukta Lanka
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v5.2
Sprint: Replication 2021-12-13, Replication 2021-12-27, Replication 2022-01-10, Replication 2022-01-24
Participants:
Linked BF Score: 135

 Description   

We don't call onCreate with the client lock, so there's a period of time where there's a new opCtx that isn't enumerable by going through the client list. When we change the storage engine for FCBIS, we first kill all opCtxes by going through the client list. Since a new opCtx might not be on the list, it can survive and will still exist after we clear the storage engine. This means the opCtx could reference a null storage engine, resulting in a segfault.



 Comments   
Comment by Githook User [ 10/Jan/22 ]

Author:

{'name': 'Samy Lanka', 'email': 'samy.lanka@mongodb.com', 'username': 'lankas'}

Message: SERVER-61934 Hold storage change lock while creating a new opCtx to prevent races with switching out the storage engine

(cherry picked from commit 9b60d431ed30814490c625c451b5c0e66a28d928)
Branch: v5.2
https://github.com/mongodb/mongo/commit/fe5da9a24783d5e3cf6e0f0f3dc2da7086c24ebd

Comment by Githook User [ 10/Jan/22 ]

Author:

{'name': 'Samy Lanka', 'email': 'samy.lanka@mongodb.com', 'username': 'lankas'}

Message: SERVER-61934 Hold storage change lock while creating a new opCtx to prevent races with switching out the storage engine
Branch: master
https://github.com/mongodb/mongo/commit/9b60d431ed30814490c625c451b5c0e66a28d928

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