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

["Christian König" <christian.koenig@amd.com>]

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.