Re: [PATCH 3/4] rust: Add dma_fence abstractions

["Danilo Krummrich" <dakr@kernel.org>]

On Wed Jun 3, 2026 at 1:22 PM CEST, Boris Brezillon wrote:
> Honestly, the more I think about it, the more I believe we should defer the
> drop unconditionally and call it a day.

I think deferring is fine, a hard synchronization with synchronize_rcu() in
DriverFence::drop() seems very undesirable though.

Another option would be to change dma_fence_is_signaled() to take the fence lock
already for signaled(), which should be fine given that drivers should only ever
check a sequence number.

It would account for the fact that the same race is possible on the C side.
While the memory allocation is protected by RCU, the contents are not, and it
seems realistic a driver could invalidate the contents of its private data after
signaling the fence while signaled() callbacks are still in flight.

Note that there are no new constraints, signaled() is already called with RCU
read lock held, plus there's also dma_fence_is_signaled_locked() which also
calls signaled() with the fence lock held.

With this, the problem goes away, as it would guarantee that once we reach
drop_in_place() in DriverFence::drop() it is impossible that there are still
callback in flight.