lock/unlock mismatch in ttm_bo.c

[Chunming Zhou]

update the fix.


On 2018年01月24日 11:09, Chunming Zhou wrote:
> 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: 1164 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20180124/28b5b73b/attachment-0001.bin>