Re: vmwgfx leaking bo pins?

[Zack Rusin <zackr@vmware.com>]

On 3/12/21 5:06 AM, Thomas Hellström (Intel) wrote:
> 
> On 3/12/21 12:02 AM, Zack Rusin wrote:
>>
>>> On Mar 11, 2021, at 17:35, Thomas Hellström (Intel) 
>>> <thomas_os@shipmail.org> wrote:
>>>
>>> Hi, Zack
>>>
>>> On 3/11/21 10:07 PM, Zack Rusin wrote:
>>>>> On Mar 11, 2021, at 05:46, Thomas Hellström (Intel) 
>>>>> <thomas_os@shipmail.org> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I tried latest drm-fixes today and saw a lot of these: Fallout from 
>>>>> ttm rework?
>>>> Yes, I fixed this in d1a73c641afd2617bd80bce8b71a096fc5b74b7e it was 
>>>> in drm-misc-next in the drm-misc tree for a while but hasn’t been 
>>>> merged for 5.12.
>>>>
>>>> z
>>>>
>>> Hmm, yes but doesn't that fix trip the ttm_bo_unpin() 
>>> dma_resv_assert_held(bo->base.resv)?
>> No, doesn’t seem to. TBH I’m not sure why myself, but it seems to be 
>> working fine.
>>
>>
> With CONFIG_PROVE_LOCKING=y I see this:
> 
> [    7.117145] [drm] FIFO at 0x00000000fe000000 size is 8192 kiB
> [    7.117284] [drm] VRAM at 0x00000000e8000000 size is 131072 kiB
> [    7.117291] INFO: trying to register non-static key.
> [    7.117295] the code is fine but needs lockdep annotation.
> [    7.117298] turning off the locking correctness validator
> 
> Which will probably mask that dma_resv_assert_held(bo->base.resv)
> 

Ah, yes, you're right. After fixing that I do see the 
dma_resv_assert_held triggered. Technically trivially fixable with 
ttm_bo_reserve/ttm_bo_unreserve around ttm_bo_unpin but it's a little 
ugly that some places e.g. vmw_bo_unreference will require 
ttm_bo_reserve/ttm_bo_unreserve around ttm_bo_unpin but some won't e.g. 
vmw_mob_destroy won't because its lock is held by ttm_bo_delayed_delete 
without a very clear indication within the function which is which.

z
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel