lock/unlock mismatch in ttm_bo.c

[He, Roger]

The patch looks fine to me, please send it to dri mail list.

Thanks
Roger(Hongbo.He)

-----Original Message-----
From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf Of Tom St Denis
Sent: Wednesday, January 24, 2018 3:25 AM
To: Zhou, David(ChunMing) <David1.Zhou at amd.com>
Cc: Koenig, Christian <Christian.Koenig at amd.com>; amd-gfx mailing list <amd-gfx at lists.freedesktop.org>
Subject: Re: lock/unlock mismatch in ttm_bo.c

On 22/01/18 01:42 AM, Chunming Zhou wrote:
> 
> 
> On 2018年01月20日 02:23, Tom St Denis wrote:
>> On 19/01/18 01:14 PM, Tom St Denis wrote:
>>> Hi all,
>>>
>>> In the function ttm_bo_cleanup_refs() it seems possible to get to 
>>> line 551 without entering the block on 516 which means you'll be 
>>> unlocking a mutex that wasn't locked.
>>>
>>> Now it might be that in the course of the API this pattern cannot be 
>>> expressed but it's not clear from the function alone that that is 
>>> the case.
>>
>>
>> Looking further it seems the behaviour depends on locking in parent 
>> callers.  That's kinda a no-no right?  Shouldn't the lock be 
>> taken/released in the same function ideally?
> Same feelings
> 
> Regards,
> David Zhou

Attached is a patch that addresses this.

I can't see any obvious race in functions that call
ttm_bo_cleanup_refs() between the time they let go of the lock and the time it's taken again in the call.

Running it on my system doesn't produce anything notable though the KASAN with DRI_PRIME=1 issue is still there (this patch neither causes that nor fixes it).

Tom