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.
