lock/unlock mismatch in ttm_bo.c

[Chunming Zhou]

Hi Tom,

Your change looks ok, as Roger suggested, you can send both dri and amd 
mail lists.

In addition, when I review your patches, I found a bug as the attached, 
you can send it together with yours if you think that's a right fix.

Regards,

David Zhou


On 2018年01月24日 03:25, Tom St Denis wrote:
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ttm-fix-double-trylock-reservation.patch
Type: text/x-patch
Size: 987 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20180124/882c4952/attachment.bin>