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

[Christian König <christian.koenig@amd.com>]

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