> Date: Sun, 23 Jul 2023 12:36:10 +0900 > From: PHO <p...@cielonegro.org> > > This: > https://github.com/depressed-pho/netbsd-src/blob/91daa67f17222da355d3fddd6fa849c786d9c545/sys/external/bsd/drm2/dist/drm/vmwgfx/vmwgfx_fence.c#L45 > > and this: > https://github.com/depressed-pho/netbsd-src/blob/91daa67f17222da355d3fddd6fa849c786d9c545/sys/external/bsd/drm2/dist/drm/vmwgfx/vmwgfx_fence.c#L527 > > vma_fence_manager::fence_list holds pointers to all the fence objects in > use but the list doesn't retain their refcount. I tried to change the > way how it works by simply incrementing the refcount in > vmw_fence_obj_init() and decrementing it in __vmw_fences_update(). But > it didn't work well because fences could also be released by > dma_resv_add_excl_fence() and dma_resv_add_shared_fence(). I cannot > recall all the details but sometimes refcounts went down to zero even if > they were retained by fence_list, and that's when I gave up fighting > against it. I admit I don't fully understand the code.
Why can't the loop just use dma_fence_get_rcu and dma_fence_put? Might need to release and reacquire the lock around dma_fence_put. If that doesn't work for some reason and we do have to add a special case, I'd strongly prefer to add a new front end like dma_fence_signal_vmwgfxspecialhack or something (other examples in the tasklet API) that has the relaxed assertion instead of relaxing the assertions for every other driver which isn't bonkers. It may add some maintenance burden, but the diagnostic burden for all the drivers is enormous too, so I'm extremely disinclined to just relax assertions here.
