btree->evict_disabled is modified in two locations:
__wt_evict_file_exclusive_on where it is accessed inside the evict_walk_lock and modified by ++ or --, and

__wt_evict_file_exclusive_off which does not take the lock and uses an atomic_sub

We have the following comment explaining why exclusive_off doesn't take the lock

/*
 * Atomically decrement the evict-disabled count, without acquiring the eviction walk-lock. We can't
 * acquire that lock here because there's a potential deadlock. When acquiring exclusive eviction
 * access, we acquire the eviction walk-lock and then the eviction's pass-intr lock. The current
 * eviction implementation can hold the pass-intr lock and call into this function (see WT-3303 for
 * the details), which might deadlock with another thread trying to get exclusive eviction access.
 */ 

however there is still a potential race as we're not using atomics or locks consistently when accessing and modifying evict_disabled.

The scope of this ticket is:

• Review the evict disabled code and see if the deadlock described above is still applicable. If not update exclusive_off to use a lock
• If this is not doable update exclusive_on to use atomic updates
• In either case add testing or asserts that can verify we're updating evict_disabled properly. As a first step we should update the WT_ASSERTs in exclusive_off to WT_ASSERT_ALWAYS