On 3/5/26 14:54, Philipp Stanner wrote: > Yo Christian, > > a while ago we were discussing this problem > > dma_fence_set_error(f, -ECANCELED); > dma_fence_signal(f); // racy! > > > I think you mentioned that you are considering to redesign the > dma_fence API so that users have to take the lock themselves to touch > the fence: > > dma_fence_lock(f); > dma_fence_set_error(f, -ECANCELED); > dma_fence_signal(f); > dme_fence_unlock(f); > > > Is that still up to date? Is there work in progress about that?
It's on my "maybe if I ever have time for that" list, but yeah I think it would be really nice to have and a great cleanup. We have a bunch of different functions which provide both a _locked() and _unlocked() variant just because callers where to lazy to lock the fence. Especially the dma_fence_signal function is overloaded 4 (!) times with locked/unlocked and with and without timestamp functions. > I discovered that I might need / want that for the Rust abstractions. Well my educated guess is for Rust you only want the locked function and never allow callers to be lazy. Regards, Christian. > > > Regards, > P.
