Re: [PATCH] dma-fence: use correct callback in dma_fence_timeline_name()

["pstanner@redhat.com" <pstanner@redhat.com>]

On Thu, 2026-06-18 at 20:30 +0200, Tvrtko Ursulin wrote:
> 
> On 18/06/2026 14:46, Christian König wrote:
> > On 6/18/26 14:00, André Draszik wrote:
> > > dma_fence_timeline_name() is a wrapper around
> > > dma_fence_ops::get_timeline_name(). Since the blamed commit below, it
> > > calls an incorrect callback.
> > > 
> > > Update it to restore functionality by calling the intended callback.
> > > 
> > > Fixes: 62918542b7bf ("dma-fence: Fix sparse warnings due __rcu annotations")
> > > Signed-off-by: André Draszik <andre.draszik@linaro.org>

Reviewed-by: Philipp Stanner <phasta@kernel.org>

> > I'm like 99% sure we had that already fixed weeks ago, but somehow it looks like that was never merged to drm-misc-fixes.

I'm also very sure that we had shot that bug down not too long in the
past.

> > 
> > Anyway Reviewed-by: Christian König <christian.koenig@amd.com>
> 
> I was also perplexed and took me some digging to realise what had happened.
> 
> The copy-and-paste bug was indeed originally fixed in:
> 
> commit 033559473dd3b55558b535aa37b8848c207b5cbb
> Author:     Akash Goel <akash.goel@arm.com>
> AuthorDate: Tue Oct 21 17:09:51 2025 +0100
> Commit:     Tvrtko Ursulin <tursulin@ursulin.net>
> CommitDate: Fri Oct 24 16:56:37 2025 +0100
> 
>      dma-fence: Fix safe access wrapper to call timeline name method
> 
> 
> But waaay before that I sent a fix for something else which touched 
> those lines not noticing the copy-and-paste, fixing a different issue. 
> That one however was not merged until earlier this year:
> 
> commit 62918542b7bf08860a60ebbde7654486e0ac0776
> Author:     Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
> AuthorDate: Mon Jun 16 16:59:52 2025 +0100
> Commit:     Christian König <christian.koenig@amd.com>
> CommitDate: Mon Feb 9 14:05:20 2026 +0100
> 
>      dma-fence: Fix sparse warnings due __rcu annotations
> 
> Notice the authored vs commited dates.
> 
> I guess it was a silent conflict which overwrote the earlier fix and 
> restore the copy-and-paste bug.

silent conflict? If that can happen with our git workflow, how is it
that we don't see things like that more often?


P.