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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
