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 <[email protected]>
> Signed-off-by: Matthew Brost <[email protected]>
Reviewed-by: Christian König <[email protected]>
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));
