Possible lock inversion in ttm_bo_vm_access

[Thomas Hellstrom]

Hi, Felix,

It looks like there is a locking inversion in ttm_bo_vm_access() where 
we take a sleeping bo_reserve() while holding mmap_sem().

Previously we've been assuming the other way around or at least 
undefined allowing for drivers to do

bo_reserve()
copy_to_user() / copy_from_user()
bo_unreserve()

I'm not sure the latter pattern is used in any drivers, though, and I 
guess there are ways around it. So it might make sense to fix the 
locking order at this point. In that case, perhaps one should add a

might_lock(&bo->resv->lock.base);

at the start of the TTM fault handler to trip lockdep on locking order 
violations in situations where the access() callback isn't commonly used...

/Thomas