[SERVER-59591] LockerNoop::isW() always returns true allowing multiple operations think they are holding the global exclusive lock at the same time Created: 25/Aug/21  Updated: 29/Oct/23  Resolved: 27/Aug/21

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

Type: Bug Priority: Major - P3
Reporter: Gregory Wlodarek Assignee: Gregory Wlodarek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Problem/Incident
Related
related to SERVER-58736 Avoid quadratic behavior in rollback ... Closed
related to SERVER-59618 Avoid using LockerNoop outside of uni... Closed
related to SERVER-60229 lock manager for mongos Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v5.0
Sprint: Execution Team 2021-09-06
Participants:
Linked BF Score: 137

 Description   

This is problematic because the profile command on mongos uses a LockerNoop and CollectionCatalog::write(). SERVER-58736 introduced an optimization to skip copying the collection catalog on write if the exclusive global lock is held. But the usage of LockerNoop in the profile command breaks this assumption given that isW() always returns true.



 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 [ 20/Sep/21 ]

Author:

{'name': 'Gregory Wlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'username': 'GWlodarek'}

Message: SERVER-59591 LockerNoop::isW() returns false

(cherry picked from commit 329b23bc73b8f143375b5c577c7d787c08699275)
Branch: v5.0
https://github.com/mongodb/mongo/commit/82507aa16a5a01b51a93431eb82ebc4ad74e04c7

Comment by Githook User [ 27/Aug/21 ]

Author:

{'name': 'Gregory Wlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'username': 'GWlodarek'}

Message: SERVER-59591 LockerNoop::isW() returns false
Branch: master
https://github.com/mongodb/mongo/commit/329b23bc73b8f143375b5c577c7d787c08699275

Comment by Gregory Wlodarek [ 26/Aug/21 ]

I've filed SERVER-59618 in an attempt to stop using LockerNoop outside of unit testing as the long-term solution.

Comment by Gregory Wlodarek [ 26/Aug/21 ]

daniel.gottlieb, I haven't looked into that. Originally I thought that LockerNoop was used to make unit testing easier, but this made me realize it's easy to make unintentional changes that affect things outside of that. We should probably reevaluate using LockerNoop outside of unit testing.

Comment by Daniel Gottlieb (Inactive) [ 26/Aug/21 ]

Not exactly pertinent question: why does a mongos use a LockerNoop?

Comment by Gregory Wlodarek [ 25/Aug/21 ]

milkie, since SERVER-58736 needs to be backported to v5.0 I think the easiest thing here is to have isW() return false as this will also need to be backported. I ran a patch here that only required two unit tests fixtures to be changed. 

I do agree that SERVER-26879 would make life easier. I spent a good portion of the day debugging the build failure only to realize the operation is using a LockerNoop.

Comment by Eric Milkie [ 25/Aug/21 ]

Yes, this is SERVER-31247 that we never changed. LockerNoOp's answers were customized to get various tests to pass, so I suspect you won't be able to just change its answer for isW() without a lot of extra work to fix all the tests that rely on it.
We wanted to do SERVER-26879 eventually but never finished it due to the amount of work.
Perhaps the simplest thing to do is avoid using LockerNoOp outside of unit tests as much as possible. Can we remove it from the profile logic?

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