On Mon, 2026-09-07 at 13:42 +0200, Christian König wrote: > Well no, before patch "035219a760ed dma-buf: dma-fence: Fix potential > NULL pointer dereference" everything worked correctly as long as the > driver waited for an RCU grace period before tearing down the > scheduler.
035219a760ed literally fixed a race condition for weakly ordered platforms, so I wouldn't say that "everything worked correctly" :) > […] > > > > > > Correct me if I'm wrong, but it seems we have not found an alternative > > solution that can work yet? > > I think we did. The problem was introduced with patch 035219a760ed > and I think we should fix it there as well. > > We just need to start checking for both the ops and signaled status > in the dma_fence framework. Agreed, we should address the problem there. But see my other answer to Tvrtko. I think if the decoupling point is the signaled bit anyways, we can and should stop setting ops to NULL in the first place. Because now we'd have two decoupling points. > > > > > > > > I hope that wasn't me because that again looks very racy. > > Why? Tvrtko added the RCU protection for that. RCU does not address ordering between signaled bit and ops pointer. > > I think that there is no way around using the spinlock. As I have > > pointed out many times, the fact that the signaled-bit is set with lock > > protection and read without it is fundamentally broken :( > > As far as I can see the RCU approach works just fine, the problem is > only that we dropped the check for the signaled bit from the common > framework and didn't considered that scheduler fence and a few other > weren't changed to not have a release callback yet. > > > > > IOW, we keep the solution presented here (removing ops->release for > > > > finished-fence) and the few drivers that check whether a fence is > > > > their > > > > own first do a locked dma_fence_is_signaled() check? > > > > > > Works for me as well, but as I said I would rather like to keep it > > > simple and stupid for backporting. > > > > If you can think of a stupid and simple solution, shoot. The only thing > > I can think of is moving the string into the dma_fence, as a hard copy > > :) > > See attached. It doesn't fully solve the problem, but it gives us the > status again we had after Tvrtko's RCU protection work. > Patch 0001 seems to reintroduce the race condition. No one guarantees that the CPU will load the signaled flag before the ops. P.
