Possible lock inversion in ttm_bo_vm_access

[Christian König]

Hi Thomas,

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

That pattern is illegal for a number of reasons and the mmap_sem is only 
one of it.

So the locking order must always be mmap_sem->bo_reservation. See the 
userptr implementation in amdgpu as well.

Christian.

Am 12.10.2018 um 16:52 schrieb 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
>
>
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel