On 6/25/26 09:25, Philipp Stanner wrote: > On Wed, 2026-06-24 at 13:13 +0200, Christian König wrote: >> Then the last piece is dropping calling enable_signaling callback with the >> dma_fence lock held. This makes it possible for backends to acquire locks >> which are semantically ordered outside of the dma_fence lock. >> >> This is necessary to allows using the dma_fence inline lock in more cases, >> previously backends used some common external lock for their dma_fences to >> for example make it possible remove fences from linked lists. > > Hi Christian, > > thx for all this work! I will review around a bit during the next days. > > For completeness, let me ask here: > Is there any relation, or any work in the pipe, which you would > consider a good solution for the race conditions described in these two > threads [1][2]? > > > Regards > P. > > > [1] > https://lore.kernel.org/dri-devel/[email protected]/
Not yet, this is just the stuff we previously discussed so far but never merged. I was thinking about adding a flag which prevents setting ops to NULL for implementations which don't desire that. > [2] > https://lore.kernel.org/dri-devel/[email protected]/ Yes, it should be possible now to rework the handling in nouveau to not rely on such behavior. The key for this is patches 8 and 9 in the series. Which allows you to have the cleanup directly after dma_fence_signal(). Regards, Christian.
