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.
