[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

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));
>>>>
>>

Claude review: drm/i915/selftests: Fix build after dma-fence locking rework

[Claude Code Review Bot]

Patch Review

The patch replaces direct `fence->lock` access with the new `dma_fence_spinlock()` accessor in two places:

> -	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 */

This is a straightforward mechanical change. Both the lock and unlock use the same accessor on the same `fence` pointer, so the lock/unlock is properly balanced. The `fence` pointer is non-NULL at this point (guarded by the `if (!fence) return;` above).

The commit message accurately describes both the problem and the fix, and correctly identifies the commit that caused the build breakage via the Fixes tag.

Christian's question in the review thread about `spin_lock_irq()` vs `spin_lock_irqsave()` is worth noting. Looking at the existing tree, `active_flush()` is called from `i915_active_unlock_wait()` under `rcu_read_lock()`, which does not alter IRQ state. The selftest calling context is process context with interrupts enabled, so `spin_lock_irq()` is technically fine here. But that's a pre-existing design choice, not something this patch introduces or changes.

No issues found in this patch.

---
Generated by Claude Code Patch Reviewer

Claude review: drm/i915/selftests: Fix build after dma-fence locking rework

[Claude Code Review Bot]

Overall Series Review

Subject: drm/i915/selftests: Fix build after dma-fence locking rework
Author: Matthew Brost <matthew.brost@intel.com>
Patches: 7
Reviewed: 2026-02-24T09:54:10.645046

---

This is a single-patch build fix for the i915_active selftest, needed after a dma-fence locking rework that inlined the spinlock into `struct dma_fence` and introduced a `dma_fence_spinlock()` accessor. The patch mechanically replaces two instances of direct `fence->lock` access with the new accessor. The change is minimal, correct, and already has Christian König's Reviewed-by.

The mailing list discussion following the patch is more interesting than the patch itself. Christian raised a pre-existing question about the use of `spin_lock_irq()` vs `spin_lock_irqsave()` in `active_flush()`, and a lockdep splat was reported in `dma_fence_chain_enable_signaling()` that Christian identified as a pre-existing bug newly exposed by the locking rework. Neither issue is introduced by this patch.

---
Generated by Claude Code Patch Reviewer