The patch looks fine to me, please send it to dri mail list. Thanks Roger(Hongbo.He)
-----Original Message----- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Tom St Denis Sent: Wednesday, January 24, 2018 3:25 AM To: Zhou, David(ChunMing) <david1.z...@amd.com> Cc: Koenig, Christian <christian.koe...@amd.com>; amd-gfx mailing list <amd-gfx@lists.freedesktop.org> Subject: Re: lock/unlock mismatch in ttm_bo.c 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 _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
