dbCheck, which initially only holds IS locks in the global hierarchy (except the FCV lock), upgrades its locks to IX when writing to the oplog.

This causes a deadlock with a concurrent setFCV command and a DDL operation, in this example, dropCollection:

• dbCheck holds all IS locks in the global hierarchy including the IS collection lock, but it doesn't hold the FCV lock, which we only take in exclusive (IX,X) lock modes.
• dropCollection holds an IX FCV lock. It waits on an X collection lock behind dbCheck
• setFCV waits on an S FCV lock behind dropCollection
• dbCheck tries to take an IX FCV lock behind the setFCV

We support lock upgrades in the lock manager. If the dbCheck operation had taken an IS FCV lock, it would have skipped the queue ahead of the waiting setFCV command, and this deadlock did not happen. This is described in this comment.

This ticket will address the deadlock concern by not upgrading the global locks in dbCheck, since this is generally dangerous.