lock/unlock mismatch in ttm_bo.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux