On Tue, 2025-11-25 at 13:20 +0000, Tvrtko Ursulin wrote: > > On 25/11/2025 10:44, Philipp Stanner wrote: > > Almost all users of dma_fence_signal() ignore the return code which > > would indicate that the fence was already signaled. The same return code > > by dma_fence_add_callback() cannot be ignored, however, because it's > > needed to detect races. > > > > For an already signaled fence, dma_fence_signal() returns -EINVAL, > > whereas dma_fence_add_callback() returns -ENOENT. > > > > Unify the error codes by having dma_fence_signal() return -ENOENT, too. > > > > Signed-off-by: Philipp Stanner <[email protected]> > > --- > > drivers/dma-buf/dma-fence.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > > index 3a48896ded62..09d97624e647 100644 > > --- a/drivers/dma-buf/dma-fence.c > > +++ b/drivers/dma-buf/dma-fence.c > > @@ -373,7 +373,7 @@ int dma_fence_signal_timestamp_locked(struct dma_fence > > *fence, > > lockdep_assert_held(fence->lock); > > > > if (unlikely(__dma_fence_is_signaled(fence))) > > - return -EINVAL; > > + return -ENOENT; > > > > /* Stash the cb_list before replacing it with the timestamp */ > > list_replace(&fence->cb_list, &cb_list); > > Story checks out AFAICT - only two callers fetch the error, xe and kfd, > and neither does anything with it. So I'd say it makes sense to unify > the errno. > > Reviewed-by: Tvrtko Ursulin <[email protected]> > > Regards, > > Tvrtko > > P.S. Just not sure of the 1/2 on which this one ends depending on. I > *think* I suggested the helper in the context of some discussion long > long time ago but what it was? And what about all the drivers which look > at the signaled bit directly?
That was in a discussion where we could have needed such a function to solve a bug in Nouveau where dma_fence_is_signaled() unexpetedely signaled a fence. AFAIR that caused locking issues in that context. The other test_bit() users could be ported, of course. P.
