Re: [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free

[Philipp Stanner <phasta@mailbox.org>]

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.