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. Regards, Christian. > > Or would your plan be to take and release the ops-lock before the > destructor to ensure all callbacks are gone? > > P.
