[SERVER-57432] Prevent MODE_X and MODE_S locks from being yielded and reacquired Created: 04/Jun/21  Updated: 29/Oct/23  Resolved: 22/Feb/22

Status: Closed
Project: Core Server
Component/s: Concurrency
Affects Version/s: None
Fix Version/s: 6.0.0-rc0

Type: Improvement Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Jordi Olivares Provencio
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-62172 Fix failure to handle stepDown within... Closed
Problem/Incident
Related
related to SERVER-57358 Build config.chunks indexes on backgr... Closed
related to SERVER-63833 Refactor CollectionBulkLoaderImpl to ... Closed
related to SERVER-65818 [5.0] Initial sync uses hybrid index ... Closed
is related to SERVER-63992 Make dropCollection in rs_rollback ne... Closed
is related to SERVER-68394 Ensure we do not yield strong locks u... Closed
Backwards Compatibility: Fully Compatible
Sprint: Execution Team 2022-02-21, Execution Team 2022-03-07
Participants:
Linked BF Score: 161

 Description   

Callers typically acquire a MODE_X lock to exclude all readers and writers and a MODE_S lock to exclude all writers. Allowing query yielding, hybrid index building, etc. to release and later reacquire these locks can invalidate assumptions about what these internal callers thought acquiring a strong lock meant within the system because it enables other readers and writers to act on the collection.

We should consider making it a programmer error to use Locker::saveLockStateAndUnlock() and/or Locker::restoreLockState() to yield and reacquire MODE_X and MODE_S locks, or consider making it a programmer error to use PlanYieldPolicy::YieldPolicy::YIELD_AUTO while holding a MODE_X or MODE_S lock. Note: The caller could instead set PlanYieldPolicy::YieldPolicy::NO_YIELD or similar with an intent lock to reflect their intention to not see the effects of other writers if they actually wanted the effects of what yielding and reacquiring strong locks would imply for some reason.



 Comments   
Comment by Louis Williams [ 28/Feb/22 ]

For what it's worth, this exposed a bug in rollback-via-refetch yielding the Global X lock: SERVER-63992.

Comment by Githook User [ 22/Feb/22 ]

Author:

{'name': 'Jordi Olivares Provencio', 'email': 'jordi.olivares-provencio@mongodb.com', 'username': 'jordiolivares'}

Message: SERVER-57432 Forbid yielding MODE_X/MODE_S locks
Branch: master
https://github.com/mongodb/mongo/commit/a0eb65c457a250baada836c0b6165e93449cd079

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