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

[Philipp Stanner]

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.

Or would your plan be to take and release the ops-lock before the
destructor to ensure all callbacks are gone?

P.