[PATCH] drm/i915/selftests: Fix build after dma-fence locking rework

[PATCH] drm/i915/selftests: Fix build after dma-fence locking rework

[Matthew Brost]

The i915_active selftest no longer builds after the dma-fence locking
rework because it directly accessed the fence’s spinlock. The helper
dma_fence_spinlock() must now be used to obtain the spinlock. Update the
selftest to use dma_fence_spinlock() accordingly.

Fixes: 1f32f310a13c ("dma-buf: inline spinlock for fence protection v5")
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
---
 drivers/gpu/drm/i915/selftests/i915_active.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_active.c b/drivers/gpu/drm/i915/selftests/i915_active.c
index 52345073b409..9fea2fabeac4 100644
--- a/drivers/gpu/drm/i915/selftests/i915_active.c
+++ b/drivers/gpu/drm/i915/selftests/i915_active.c
@@ -323,9 +323,9 @@ static void active_flush(struct i915_active *ref,
 	if (!fence)
 		return;
 
-	spin_lock_irq(fence->lock);
+	spin_lock_irq(dma_fence_spinlock(fence));
 	__list_del_entry(&active->cb.node);
-	spin_unlock_irq(fence->lock); /* serialise with fence->cb_list */
+	spin_unlock_irq(dma_fence_spinlock(fence)); /* serialise with fence->cb_list */
 	atomic_dec(&ref->count);
 
 	GEM_BUG_ON(!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
-- 
2.34.1

✗ Fi.CI.BUILD: failure for drm/i915/selftests: Fix build after dma-fence locking rework

[Patchwork]

== Series Details ==

Series: drm/i915/selftests: Fix build after dma-fence locking rework
URL   : https://patchwork.freedesktop.org/series/161998/
State : failure

== Summary ==

Error: make failed
  CALL    scripts/checksyscalls.sh
  DESCEND objtool
  INSTALL libsubcmd_headers
  CC [M]  drivers/gpu/drm/i915/i915_active.o
In file included from drivers/gpu/drm/i915/i915_active.c:1174:
drivers/gpu/drm/i915/selftests/i915_active.c: In function ‘active_flush’:
drivers/gpu/drm/i915/selftests/i915_active.c:326:23: error: implicit declaration of function ‘dma_fence_spinlock’; did you mean ‘dma_fence_signal’? [-Werror=implicit-function-declaration]
  326 |         spin_lock_irq(dma_fence_spinlock(fence));
      |                       ^~~~~~~~~~~~~~~~~~
      |                       dma_fence_signal
drivers/gpu/drm/i915/selftests/i915_active.c:326:23: error: passing argument 1 of ‘spin_lock_irq’ makes pointer from integer without a cast [-Werror=int-conversion]
  326 |         spin_lock_irq(dma_fence_spinlock(fence));
      |                       ^~~~~~~~~~~~~~~~~~~~~~~~~
      |                       |
      |                       int
In file included from ./include/linux/debugobjects.h:6,
                 from drivers/gpu/drm/i915/i915_active.c:7:
./include/linux/spinlock.h:368:55: note: expected ‘spinlock_t *’ {aka ‘struct spinlock *’} but argument is of type ‘int’
  368 | static __always_inline void spin_lock_irq(spinlock_t *lock)
      |                                           ~~~~~~~~~~~~^~~~
drivers/gpu/drm/i915/selftests/i915_active.c:328:25: error: passing argument 1 of ‘spin_unlock_irq’ makes pointer from integer without a cast [-Werror=int-conversion]
  328 |         spin_unlock_irq(dma_fence_spinlock(fence)); /* serialise with fence->cb_list */
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~
      |                         |
      |                         int
./include/linux/spinlock.h:398:57: note: expected ‘spinlock_t *’ {aka ‘struct spinlock *’} but argument is of type ‘int’
  398 | static __always_inline void spin_unlock_irq(spinlock_t *lock)
      |                                             ~~~~~~~~~~~~^~~~
cc1: all warnings being treated as errors
make[6]: *** [scripts/Makefile.build:289: drivers/gpu/drm/i915/i915_active.o] Error 1
make[5]: *** [scripts/Makefile.build:546: drivers/gpu/drm/i915] Error 2
make[4]: *** [scripts/Makefile.build:546: drivers/gpu/drm] Error 2
make[3]: *** [scripts/Makefile.build:546: drivers/gpu] Error 2
make[2]: *** [scripts/Makefile.build:546: drivers] Error 2
make[1]: *** [/home/kbuild2/kernel/Makefile:2101: .] Error 2
make: *** [Makefile:248: __sub-make] Error 2
Build failed, no error log produced

RE: [PATCH] drm/i915/selftests: Fix build after dma-fence locking rework

[Cavitt, Jonathan]

-----Original Message-----
From: Intel-xe <intel-xe-bounces@lists.freedesktop.org> On Behalf Of Matthew Brost
Sent: Monday, February 23, 2026 9:26 AM
To: intel-xe@lists.freedesktop.org; dri-devel@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
Cc: Christian König <christian.koenig@amd.com>
Subject: [PATCH] drm/i915/selftests: Fix build after dma-fence locking rework
> 
> The i915_active selftest no longer builds after the dma-fence locking
> rework because it directly accessed the fence’s spinlock. The helper
> dma_fence_spinlock() must now be used to obtain the spinlock. Update the
> selftest to use dma_fence_spinlock() accordingly.
> 
> Fixes: 1f32f310a13c ("dma-buf: inline spinlock for fence protection v5")
> Cc: Christian König <christian.koenig@amd.com>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>

Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
-Jonathan Cavitt

> ---
>  drivers/gpu/drm/i915/selftests/i915_active.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/selftests/i915_active.c b/drivers/gpu/drm/i915/selftests/i915_active.c
> index 52345073b409..9fea2fabeac4 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_active.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_active.c
> @@ -323,9 +323,9 @@ static void active_flush(struct i915_active *ref,
>  	if (!fence)
>  		return;
>  
> -	spin_lock_irq(fence->lock);
> +	spin_lock_irq(dma_fence_spinlock(fence));
>  	__list_del_entry(&active->cb.node);
> -	spin_unlock_irq(fence->lock); /* serialise with fence->cb_list */
> +	spin_unlock_irq(dma_fence_spinlock(fence)); /* serialise with fence->cb_list */
>  	atomic_dec(&ref->count);
>  
>  	GEM_BUG_ON(!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
> -- 
> 2.34.1
> 
> 

Re: [PATCH] drm/i915/selftests: Fix build after dma-fence locking rework

[Christian König]

On 2/23/26 18:25, Matthew Brost wrote:
> The i915_active selftest no longer builds after the dma-fence locking
> rework because it directly accessed the fence’s spinlock. The helper
> dma_fence_spinlock() must now be used to obtain the spinlock. Update the
> selftest to use dma_fence_spinlock() accordingly.
> 
> Fixes: 1f32f310a13c ("dma-buf: inline spinlock for fence protection v5")
> Cc: Christian König <christian.koenig@amd.com>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>

Reviewed-by: Christian König <christian.koenig@amd.com>

Thanks for the patch and sorry for the noise, just one more question below.

> ---
>  drivers/gpu/drm/i915/selftests/i915_active.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/selftests/i915_active.c b/drivers/gpu/drm/i915/selftests/i915_active.c
> index 52345073b409..9fea2fabeac4 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_active.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_active.c
> @@ -323,9 +323,9 @@ static void active_flush(struct i915_active *ref,
>  	if (!fence)
>  		return;
>  
> -	spin_lock_irq(fence->lock);
> +	spin_lock_irq(dma_fence_spinlock(fence));

Is it guaranteed that this is called from interrupt context? E.g. why is spin_lock_irq() instead of spin_lock_irqsafe() used here?

That's basically the reason why I missed this.

Regards,
Christian.

>  	__list_del_entry(&active->cb.node);
> -	spin_unlock_irq(fence->lock); /* serialise with fence->cb_list */
> +	spin_unlock_irq(dma_fence_spinlock(fence)); /* serialise with fence->cb_list */
>  	atomic_dec(&ref->count);
>  
>  	GEM_BUG_ON(!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));

Re: [PATCH] drm/i915/selftests: Fix build after dma-fence locking rework

[Matthew Brost]

On Mon, Feb 23, 2026 at 08:13:34PM +0100, Christian König wrote:
> On 2/23/26 18:25, Matthew Brost wrote:
> > The i915_active selftest no longer builds after the dma-fence locking
> > rework because it directly accessed the fence’s spinlock. The helper
> > dma_fence_spinlock() must now be used to obtain the spinlock. Update the
> > selftest to use dma_fence_spinlock() accordingly.
> > 
> > Fixes: 1f32f310a13c ("dma-buf: inline spinlock for fence protection v5")
> > Cc: Christian König <christian.koenig@amd.com>
> > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> 
> Reviewed-by: Christian König <christian.koenig@amd.com>
> 
> Thanks for the patch and sorry for the noise, just one more question below.
> 
> > ---
> >  drivers/gpu/drm/i915/selftests/i915_active.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/selftests/i915_active.c b/drivers/gpu/drm/i915/selftests/i915_active.c
> > index 52345073b409..9fea2fabeac4 100644
> > --- a/drivers/gpu/drm/i915/selftests/i915_active.c
> > +++ b/drivers/gpu/drm/i915/selftests/i915_active.c
> > @@ -323,9 +323,9 @@ static void active_flush(struct i915_active *ref,
> >  	if (!fence)
> >  		return;
> >  
> > -	spin_lock_irq(fence->lock);
> > +	spin_lock_irq(dma_fence_spinlock(fence));
> 
> Is it guaranteed that this is called from interrupt context? E.g. why is spin_lock_irq() instead of spin_lock_irqsafe() used here?
> 

Idk, this i915 stuff I’ve long intentionally tried to forget to avoid nightmares.

> That's basically the reason why I missed this.
> 

Also, please include the intel-xe list for CI — that will catch issues as well.

We’re making it a bit further now, but we’re hitting a lockdep splat [1].

I can dig into it now; hopefully it’s an easy fix. If not, I may ask for
a revert. Give me an hour or so to look into it and I’ll report back.
But again, please include the intel-xe list for CI on risky DRM common
or dma-buf patches — if the patches apply to drm-tip, CI will run. You
should have permission to trigger this; I believe all AMD emails do.

Matt  

[1] https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-161999v1/bat-ptl-1/igt@xe_compute@compute-square.html

> Regards,
> Christian.
> 
> >  	__list_del_entry(&active->cb.node);
> > -	spin_unlock_irq(fence->lock); /* serialise with fence->cb_list */
> > +	spin_unlock_irq(dma_fence_spinlock(fence)); /* serialise with fence->cb_list */
> >  	atomic_dec(&ref->count);
> >  
> >  	GEM_BUG_ON(!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
> 

Re: [PATCH] drm/i915/selftests: Fix build after dma-fence locking rework

[Christian König]

On 2/23/26 20:20, Matthew Brost wrote:
> On Mon, Feb 23, 2026 at 08:13:34PM +0100, Christian König wrote:
>> On 2/23/26 18:25, Matthew Brost wrote:
>>> The i915_active selftest no longer builds after the dma-fence locking
>>> rework because it directly accessed the fence’s spinlock. The helper
>>> dma_fence_spinlock() must now be used to obtain the spinlock. Update the
>>> selftest to use dma_fence_spinlock() accordingly.
>>>
>>> Fixes: 1f32f310a13c ("dma-buf: inline spinlock for fence protection v5")
>>> Cc: Christian König <christian.koenig@amd.com>
>>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>>
>> Reviewed-by: Christian König <christian.koenig@amd.com>
>>
>> Thanks for the patch and sorry for the noise, just one more question below.
>>
>>> ---
>>>  drivers/gpu/drm/i915/selftests/i915_active.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/selftests/i915_active.c b/drivers/gpu/drm/i915/selftests/i915_active.c
>>> index 52345073b409..9fea2fabeac4 100644
>>> --- a/drivers/gpu/drm/i915/selftests/i915_active.c
>>> +++ b/drivers/gpu/drm/i915/selftests/i915_active.c
>>> @@ -323,9 +323,9 @@ static void active_flush(struct i915_active *ref,
>>>  	if (!fence)
>>>  		return;
>>>  
>>> -	spin_lock_irq(fence->lock);
>>> +	spin_lock_irq(dma_fence_spinlock(fence));
>>
>> Is it guaranteed that this is called from interrupt context? E.g. why is spin_lock_irq() instead of spin_lock_irqsafe() used here?
>>
> 
> Idk, this i915 stuff I’ve long intentionally tried to forget to avoid nightmares.
> 
>> That's basically the reason why I missed this.
>>
> 
> Also, please include the intel-xe list for CI — that will catch issues as well.
> 
> We’re making it a bit further now, but we’re hitting a lockdep splat [1].

^^ that actually looks like a bug in dma_fence_chain_enable_signaling() which was there before the patch set and now just get bubbled up because lockdep can finally check on it.

Just reverting "dma-buf: use inline lock for the dma-fence-chain" should silence that again, but it is clearly not the right fix.

> I can dig into it now; hopefully it’s an easy fix. If not, I may ask for
> a revert. Give me an hour or so to look into it and I’ll report back.
> But again, please include the intel-xe list for CI on risky DRM common
> or dma-buf patches — if the patches apply to drm-tip, CI will run. You
> should have permission to trigger this; I believe all AMD emails do.

I did that on an older version of the patch set but never got a report back. My assumption was that it's working but could be that this actually never ran.

Regards,
Christian.

> 
> Matt  
> 
> [1] https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-161999v1/bat-ptl-1/igt@xe_compute@compute-square.html
> 
>> Regards,
>> Christian.
>>
>>>  	__list_del_entry(&active->cb.node);
>>> -	spin_unlock_irq(fence->lock); /* serialise with fence->cb_list */
>>> +	spin_unlock_irq(dma_fence_spinlock(fence)); /* serialise with fence->cb_list */
>>>  	atomic_dec(&ref->count);
>>>  
>>>  	GEM_BUG_ON(!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
>>

Re: [PATCH] drm/i915/selftests: Fix build after dma-fence locking rework

[Matthew Brost]

On Mon, Feb 23, 2026 at 08:33:05PM +0100, Christian König wrote:
> On 2/23/26 20:20, Matthew Brost wrote:
> > On Mon, Feb 23, 2026 at 08:13:34PM +0100, Christian König wrote:
> >> On 2/23/26 18:25, Matthew Brost wrote:
> >>> The i915_active selftest no longer builds after the dma-fence locking
> >>> rework because it directly accessed the fence’s spinlock. The helper
> >>> dma_fence_spinlock() must now be used to obtain the spinlock. Update the
> >>> selftest to use dma_fence_spinlock() accordingly.
> >>>
> >>> Fixes: 1f32f310a13c ("dma-buf: inline spinlock for fence protection v5")
> >>> Cc: Christian König <christian.koenig@amd.com>
> >>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> >>
> >> Reviewed-by: Christian König <christian.koenig@amd.com>
> >>
> >> Thanks for the patch and sorry for the noise, just one more question below.
> >>
> >>> ---
> >>>  drivers/gpu/drm/i915/selftests/i915_active.c | 4 ++--
> >>>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/selftests/i915_active.c b/drivers/gpu/drm/i915/selftests/i915_active.c
> >>> index 52345073b409..9fea2fabeac4 100644
> >>> --- a/drivers/gpu/drm/i915/selftests/i915_active.c
> >>> +++ b/drivers/gpu/drm/i915/selftests/i915_active.c
> >>> @@ -323,9 +323,9 @@ static void active_flush(struct i915_active *ref,
> >>>  	if (!fence)
> >>>  		return;
> >>>  
> >>> -	spin_lock_irq(fence->lock);
> >>> +	spin_lock_irq(dma_fence_spinlock(fence));
> >>
> >> Is it guaranteed that this is called from interrupt context? E.g. why is spin_lock_irq() instead of spin_lock_irqsafe() used here?
> >>
> > 
> > Idk, this i915 stuff I’ve long intentionally tried to forget to avoid nightmares.
> > 
> >> That's basically the reason why I missed this.
> >>
> > 
> > Also, please include the intel-xe list for CI — that will catch issues as well.
> > 
> > We’re making it a bit further now, but we’re hitting a lockdep splat [1].
> 
> ^^ that actually looks like a bug in dma_fence_chain_enable_signaling() which was there before the patch set and now just get bubbled up because lockdep can finally check on it.
> 
> Just reverting "dma-buf: use inline lock for the dma-fence-chain" should silence that again, but it is clearly not the right fix.
> 

Ah, ok. Well let's just figure this out properly.

> > I can dig into it now; hopefully it’s an easy fix. If not, I may ask for
> > a revert. Give me an hour or so to look into it and I’ll report back.
> > But again, please include the intel-xe list for CI on risky DRM common
> > or dma-buf patches — if the patches apply to drm-tip, CI will run. You
> > should have permission to trigger this; I believe all AMD emails do.
> 
> I did that on an older version of the patch set but never got a report back. My assumption was that it's working but could be that this actually never ran.
> 

Got a link? I working on recreating this now on my dev box. Any hints to
speed up verifying a fix would be helpful.

Matt

> Regards,
> Christian.
> 
> > 
> > Matt  
> > 
> > [1] https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-161999v1/bat-ptl-1/igt@xe_compute@compute-square.html
> > 
> >> Regards,
> >> Christian.
> >>
> >>>  	__list_del_entry(&active->cb.node);
> >>> -	spin_unlock_irq(fence->lock); /* serialise with fence->cb_list */
> >>> +	spin_unlock_irq(dma_fence_spinlock(fence)); /* serialise with fence->cb_list */
> >>>  	atomic_dec(&ref->count);
> >>>  
> >>>  	GEM_BUG_ON(!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
> >>
> 

Re: [PATCH] drm/i915/selftests: Fix build after dma-fence locking rework

[Christian König]

On 2/23/26 20:36, Matthew Brost wrote:
> On Mon, Feb 23, 2026 at 08:33:05PM +0100, Christian König wrote:
>> On 2/23/26 20:20, Matthew Brost wrote:
>>> On Mon, Feb 23, 2026 at 08:13:34PM +0100, Christian König wrote:
>>>> On 2/23/26 18:25, Matthew Brost wrote:
>>>>> The i915_active selftest no longer builds after the dma-fence locking
>>>>> rework because it directly accessed the fence’s spinlock. The helper
>>>>> dma_fence_spinlock() must now be used to obtain the spinlock. Update the
>>>>> selftest to use dma_fence_spinlock() accordingly.
>>>>>
>>>>> Fixes: 1f32f310a13c ("dma-buf: inline spinlock for fence protection v5")
>>>>> Cc: Christian König <christian.koenig@amd.com>
>>>>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>>>>
>>>> Reviewed-by: Christian König <christian.koenig@amd.com>
>>>>
>>>> Thanks for the patch and sorry for the noise, just one more question below.
>>>>
>>>>> ---
>>>>>  drivers/gpu/drm/i915/selftests/i915_active.c | 4 ++--
>>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/selftests/i915_active.c b/drivers/gpu/drm/i915/selftests/i915_active.c
>>>>> index 52345073b409..9fea2fabeac4 100644
>>>>> --- a/drivers/gpu/drm/i915/selftests/i915_active.c
>>>>> +++ b/drivers/gpu/drm/i915/selftests/i915_active.c
>>>>> @@ -323,9 +323,9 @@ static void active_flush(struct i915_active *ref,
>>>>>  	if (!fence)
>>>>>  		return;
>>>>>  
>>>>> -	spin_lock_irq(fence->lock);
>>>>> +	spin_lock_irq(dma_fence_spinlock(fence));
>>>>
>>>> Is it guaranteed that this is called from interrupt context? E.g. why is spin_lock_irq() instead of spin_lock_irqsafe() used here?
>>>>
>>>
>>> Idk, this i915 stuff I’ve long intentionally tried to forget to avoid nightmares.
>>>
>>>> That's basically the reason why I missed this.
>>>>
>>>
>>> Also, please include the intel-xe list for CI — that will catch issues as well.
>>>
>>> We’re making it a bit further now, but we’re hitting a lockdep splat [1].
>>
>> ^^ that actually looks like a bug in dma_fence_chain_enable_signaling() which was there before the patch set and now just get bubbled up because lockdep can finally check on it.
>>
>> Just reverting "dma-buf: use inline lock for the dma-fence-chain" should silence that again, but it is clearly not the right fix.
>>
> 
> Ah, ok. Well let's just figure this out properly.

That is a bit of wider change, let's just revert that one for now.

> 
>>> I can dig into it now; hopefully it’s an easy fix. If not, I may ask for
>>> a revert. Give me an hour or so to look into it and I’ll report back.
>>> But again, please include the intel-xe list for CI on risky DRM common
>>> or dma-buf patches — if the patches apply to drm-tip, CI will run. You
>>> should have permission to trigger this; I believe all AMD emails do.
>>
>> I did that on an older version of the patch set but never got a report back. My assumption was that it's working but could be that this actually never ran.
>>
> 
> Got a link? I working on recreating this now on my dev box. Any hints to
> speed up verifying a fix would be helpful.

I would need to dig that up as well. IIRC that was one of the first versions with your XE patches still in the set.

I stopped CCing driver specific lists after dropping driver patches, that was probably a mistake.

Anyway lesson learned (again).

Christian.

> 
> Matt
> 
>> Regards,
>> Christian.
>>
>>>
>>> Matt  
>>>
>>> [1] https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-161999v1/bat-ptl-1/igt@xe_compute@compute-square.html
>>>
>>>> Regards,
>>>> Christian.
>>>>
>>>>>  	__list_del_entry(&active->cb.node);
>>>>> -	spin_unlock_irq(fence->lock); /* serialise with fence->cb_list */
>>>>> +	spin_unlock_irq(dma_fence_spinlock(fence)); /* serialise with fence->cb_list */
>>>>>  	atomic_dec(&ref->count);
>>>>>  
>>>>>  	GEM_BUG_ON(!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
>>>>
>>