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.
