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

[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?


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.


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?


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kern.log
Type: text/x-log
Size: 9635 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20171108/b60fa43c/attachment.bin>