Access to CollectionShardingRuntime state can be safeguarded by blocking on access to the mutex added to the CollectionShardingRuntime. This mutex is accessed by taking the new CSRLock. This will unblock these uses of the UninterruptibleLockGuard.

https://github.com/mongodb/mongo/blob/dcf7e0dd89d34f58b592f1adb3d41e5edd6e2012/src/mongo/db/s/collection_sharding_runtime.cpp#L190
https://github.com/mongodb/mongo/blob/dcf7e0dd89d34f58b592f1adb3d41e5edd6e2012/src/mongo/db/s/migration_destination_manager.cpp#L1150
https://github.com/mongodb/mongo/blob/dcf7e0dd89d34f58b592f1adb3d41e5edd6e2012/src/mongo/db/s/migration_source_manager.cpp#L444
https://github.com/mongodb/mongo/blob/dcf7e0dd89d34f58b592f1adb3d41e5edd6e2012/src/mongo/db/s/migration_source_manager.cpp#L480
https://github.com/mongodb/mongo/blob/dcf7e0dd89d34f58b592f1adb3d41e5edd6e2012/src/mongo/db/s/migration_source_manager.cpp#L679

Functions that will now be protected by the CSRLock:

CSS::enterCriticalSectionCatchUpPhase (Collection X Lock, CSR X Lock)
CSS::enterCriticalSectionCommitPhase (Collection X Lock, CSR X Lock)
CSS::exitCriticalSection (Collection X IX Lock, CSR X Lock)
CSS::getCurrentMetadataIfKnown (Collection X IS or IX Lock?, CSR IS Lock)* Need further clarification on the collection locks necessary to be used here. Multiple cases use either IX or IS.
CSR::setFilteringMetadata (Collection X Lock, CSR X Lock)
CSR::clearFilteringMetadata (Collection X IX Lock, CSR X Lock)
CollectionCriticalSection::constructor (Collection X Lock, CSR X Lock)
CollectionCriticalSection::destructor (Collection X IX Lock, CSR X Lock)
CollectionCriticalSection::enterCommitPhase (Collection X Lock, CSR X Lock)

*An exception will be made with a ..._withoutLock function for CSS::CSSMap::report, because we already hold the CSSMap mutex here, and don't want to take collection locks for the general reporting of the state of the CSSMap.

Update 1/22/18

After discussion with kaloian.manassiev and renctan we have decided to back out of some of the intended changes. Since the CollectionShardingRuntime's _metadataManager variable has an internal mutex, we do not need to take the CSRLock in cases where we are only interacting with that variable. We can simply downgrade the collection lock to MODE_IX in these cases. This includes:

MigrationDestinationManager::_forgetPending
MigrationSourceManager::commitChunkMetadataOnConfig error handling section 1
MigrationSourceManager::commitChunkMetadataOnConfig error handling section 2

In MigrationSourceManager::cleanup we will take the collection IX lock, and take the CSRLock in exclusive mode to protect changes to state variables (MigrationSourceManager, CriticalSection) on the CollectionShardingRuntime.

We will still need to modify function signatures around the critical section to offer synchronization with modification of the critical section. These changes still apply:

CSS::enterCriticalSectionCatchUpPhase (Collection X Lock, CSR X Lock)
CSS::enterCriticalSectionCommitPhase (Collection X Lock, CSR X Lock)
CSS::exitCriticalSection (Collection X IX Lock, CSR X Lock)
CollectionCriticalSection::constructor (Collection X Lock, CSR X Lock)
CollectionCriticalSection::destructor (Collection X IX Lock, CSR X Lock)
CollectionCriticalSection::enterCommitPhase (Collection X Lock, CSR X Lock)

as well as a CSRLock in MODE_IS in a section in CollectionShardingState::checkShardVersionOrThrow where we check the state of the critical section variable.