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>
