On Thu, 2025-11-27 at 10:08 -0500, Kuehling, Felix wrote: > On 2025-11-27 04:55, Christian König wrote: > > On 11/27/25 10:48, Philipp Stanner wrote: > > >
[…] > > > The issue now is that dma_fence_signal()'s return code is actually non- > > > racy, because check + bit-set are protected by lock. > > > > > > Christian's new spinlock series would add a lock function for fences: > > > https://lore.kernel.org/dri-devel/[email protected]/ > > > > > > > > > So I suppose this should work: > > > > > > dma_fence_lock_irqsave(ef, flags); > > > if (dma_fence_test_signaled_flag(ef)) { > > > dma_fence_unlock_irqrestore(ef, flags); > > > return true; > > > } > > > dma_fence_signal_locked(ef); > > > dma_fence_unlock_irqrestore(ef, flags); > > > > > > return false; > > > > > > > > > + some cosmetic adjustments for the boolean of course. > > > > > > > > > Would that fly and be reasonable? @Felix, Christian. > > I was just about to reply with the same idea when your mail arrived. > > I agree as well. The important feature is that we need to test and > signal the fence atomically. It may even make sense to add a function > for that "dma_fence_test_and_signal" that preserves the original > behaviour of dma_fence_signal. ;) Fine by me if the maintainer agrees P.
