On 10/20/26 12:00, Philipp Stanner wrote: > In our Rust code bases, I'm currently experiencing what we also > experience in C at many places: that the dma_fence contract's RCU > requirements make the API more fragile and put an unnecessary burden on > the API user. Most notably, in C the API behaving correctly now depends > on the API *user* waiting before free()s, waiting before unloads – all > because dma_fence is not properly synchronized. > > The patches commit messages give more details about where I want to go > with this particular RFC. > > My rough "vision" for dma_fence, where I think it should develop to, can > be described like this: > > 1. All users should use inline-lock. > 2. The fence-signaled state should be our decoupling point. > 3. The fence state must be consistently locked.
> 4. This means all callbacks are only invoked for unsignaled fences, and > the fence cannot signal while a callback runs. First of all that prevents concurrent execution of the callbacks which for a lot of use cases is a must have. Then as I pointed out before the second problem is that this again makes the existing lock inversion between the signaling by polling and signaling by interrupts even worse than it already is. What we could use is an SRCU, but a spinlock or any kind of lock is clearly the wrong approach. So as far as I can see that is a big no-go and we should really just use RCU for everything and remove leaking the fence look into the callbacks like I outlined before. Regards, Christian. > 5. All fence API functions should be "atomically correct": they can > always be called without any manual RCU guards in their proximity. > 6. The fence lock should, in the long-term, become inaccessible for > users. > > Point №6 means that this: > > dma_fence_lock_irqsave(…); > dma_fence_set_error(f, err); > dma_fence_signal_locked(f); > dma_fence_unlock_irqrestore(…); > synchronize_rcu(); > kfree(driver_foo); > > should simply become this: > > dma_fence_signal(f, err); > kfree(driver_foo); > > So we would end up with a simpler, more robust and more maintainable > API. > > I gave this basic testing on a Nouveau desktop and it runs fine. > dma-buf-tests also run fine. I can do more tests on Xe and amdgpu, maybe > on Mali, too. > > Since the series is mostly about locking the callbacks, all of which > except for set_deadline() are *already* locked, I am confident that this > can be done. > > Feedback welcome > > P. > > Philipp Stanner (3): > dma-fence: Remove RCU protection for fence->ops > dma-fence: use lock to protect against module-unload > dma-fence: Support unload for ops->get_XXX_name() > > drivers/dma-buf/dma-fence.c | 144 +++++++------------- > drivers/dma-buf/sync_file.c | 29 ++-- > drivers/gpu/drm/i915/gt/intel_gt_requests.c | 16 +-- > drivers/gpu/drm/i915/i915_request.c | 9 +- > drivers/gpu/drm/i915/i915_sw_fence.c | 15 +- > include/linux/dma-fence.h | 63 ++++----- > include/trace/events/dma_fence.h | 12 +- > 7 files changed, 113 insertions(+), 175 deletions(-) >
