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-drm-ttm-Force-lock-to-be-taken-released-inside-ttm_b.patch Type: text/x-patch Size: 2896 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20180123/c30b55a3/attachment.bin>
