lock/unlock mismatch in ttm_bo.c
Christian König
ckoenig.leichtzumerken at gmail.com
Sat Jan 20 14:46:18 UTC 2018
Am 19.01.2018 um 19:23 schrieb Tom St Denis:
> 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?
Yeah, that used to be a really mess in TTM. Started to work on cleaning
this up, but well you know only two hands and one head :)
> Shouldn't the lock be taken/released in the same function ideally?
>
> (also there are a handful of style issues I'll write up some patches
> for on Monday :-)).
Feel free to provide cleanup patches for both issues, they would be very
welcome I think.
Regards,
Christian.
>
> 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