[SERVER-38404] lockComplete can incorrectly skip checking if the operation context was killed, if the lock is granted quickly Created: 05/Dec/18  Updated: 29/Oct/23  Resolved: 14/Dec/18

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 4.1.7

Type: Bug Priority: Major - P3
Reporter: Samyukta Lanka Assignee: Louis Williams
Resolution: Fixed Votes: 0
Labels: prepare_interruptibility, uninterruptibleLockGuardRemoval
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Storage NYC 2018-12-17
Participants:

 Description   

When waiting for the request to be granted when calling lockComplete, the predicate could initially return true when we call waitForConditionOrInterrupt. This would mean that we never check if the operation context was killed, and so the operation continues even if it had been killed. This can happen if the lock request was granted very quickly after lockComplete is called.



 Comments   
Comment by Githook User [ 14/Dec/18 ]

Author:

{'username': 'louiswilliams', 'email': 'louis.williams@mongodb.com', 'name': 'Louis Williams'}

Message: SERVER-38404 lockComplete can incorrectly skip checking if the operation context was killed, if the lock is granted quickly
Branch: master
https://github.com/mongodb/mongo/commit/a8a31599ee42125071e9c1b5033d114444a2e40f

Comment by Samyukta Lanka [ 11/Dec/18 ]

louis.williams, yes that is the scenario we want to prevent from happening.

Comment by Louis Williams [ 06/Dec/18 ]

The issue is specifically related to how the database handles shutdown with prepared transactions. samy.lanka correct my if this is wrong.

thread A: command dropCollection "test"
thread B: shutdown

  • A: calls lockBegin(MODE_X): this blocks because there are prepared transactions holding IX locks
  • B: marks all operations as killed
  • B: aborts all transactions
  • A: calls lockComplete(): this immediately succeeds and is able to drop a collection, even though it was marked killed

This scenario is problematic because we should not be allowed to perform DDL operations on a database after transactions have been prepared.

Generated at Thu Feb 08 04:48:51 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.