lock/unlock mismatch in ttm_bo.c
Tom St Denis
tom.stdenis at amd.com
Mon Jan 22 11:29:58 UTC 2018
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
Hi David,
Ok I'll see if I can sort this out.
Cheers,
Tom
>
> Regards,
> David Zhou
>>
>> (also there are a handful of style issues I'll write up some patches
>> for on Monday :-)).
>>
>> Cheers,
>> Tom
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
More information about the amd-gfx
mailing list