[PATCH 2/4] drm/ttm: consistently use reservation_object_unlock

[Christian König]

Am 08.11.2017 um 18:37 schrieb Michel Dänzer:
> On 08/11/17 05:41 PM, Christian König wrote:
>> Am 08.11.2017 um 17:36 schrieb Michel Dänzer:
>>> On 08/11/17 03:59 PM, Christian König wrote:
>>>> Instead of having a pointless wrapper or call the underlying ww_mutex
>>>> function directly.
>>> Not sure I can agree it's pointless, since it recently took me a while
>>> to realize that unlocking bo->resv is essentially the same as
>>> unreserving the BO.
>> Ok in this case let's call this confusing. But yeah that
>> __ttm_bo_unreserv(bo), reservation_object_unlock(bo->resv) and
>> ww_mutex_unlock(&bo->resv->lock) are essentially the same thing is
>> exactly what I want to fix here.
> How about always using __ttm_bo_unreserve instead?

I actually want to get rid of __ttm_bo_reserve as well. Cause what is 
easier to understand:

__ttm_bo_reserve(bo, false, false, NULL) vs. 
reservation_object_lock(bo->resv);

__ttm_bo_reserve(bo, false, true, NULL) vs. 
reservation_object_trylock(bo->resv);

__ttm_bo_reserve(bo, true, false, NULL) vs. 
reservation_object_lock_interruptible(bo->resv);

> The first piglit run with this series applied hit the BUG_ON in
> ttm_bo_add_to_lru, see the attached dmesg excerpt. The machine hung,
> couldn't reboot cleanly. Haven't been able to reproduce it in three more
> attempts though, so I'm not sure it's caused by this series, but I don't
> remember seeing it before.

It's most likely caused by this change, I will take another look tomorrow.

> P.S. I just noticed I haven't had CONFIG_PROVE_LOCKING enabled in my
> kernels for a while, I'll enable it again. Any other options that should
> be enabled for testing?

kmemleak is quite nice to have available as well, but doesn't need to 
run automatically all the time.

Christian.