Re: [RFC PATCH] dma-fence: Fix races of fence callbacks versus destructors by locking

[Philipp Stanner <phasta@mailbox.org>]

On Tue, 2026-06-09 at 10:47 +0200, Christian König wrote:
> On 6/9/26 10:43, Philipp Stanner wrote:
> > On Mon, 2026-06-08 at 18:16 +0200, Boris Brezillon wrote:
> > > If I were to choose, I'd probably go for a dedicated rwlock_t to
> > 
> > side note:
> > rw_locks are officially discouraged AFAIK. They utilize more of the
> > expensive instructions than a spinlock and are only worth it if the
> > read section is really long compared to the write section.
> > 
> > > protect dma_fence_ops, so we can:
> > > 
> > > - protect all dma_buf_ops::xx() consistently no matter the kind
> > > of op
> > > - protect returned data (get_xxx_name()) with this lock instead
> > > of the
> > >   RCU read lock
> > 
> > That doesn't solve our Rust destructor problem though, does it?
> > 
> > What we want to do is:
> > 
> >    1. Signal the fence before it drops
> >    2. Wait for all accessors to be gone
> >    3. Run the destructor
> > 
> > Step #2 by definition demands the signaled-state lock.
> 
> If I'm not completely mistaken that approach won't work.
> 
> See you can't have a destructor if the dma_fence is independent of
> the module it issued.
> 
> That's why we have all the handling for inline lock and fence
> independents.

It does work if you have two fence types, one for the producer and one
for the consumers.

The producer type has a destructor, and with Rust you can ensure that
all producer-fences get signaled and deconstructed before module
unload.

That relies on the work done by you and Tvrtko in C, where the
signaled-state is the point of decoupling.

The only additional thing I'd need now would be to make this a hard
synchronization point that cannot race / does not need an RCU delay :)


P.