nouveau: fix client work fence deletion race

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2160457
Upstream Status: git://anongit.freedesktop.org/drm/drm

commit c8a5d5e
Author:     Dave Airlie <airlied@redhat.com>
AuthorDate: Thu Jun 15 12:22:11 2023 +1000
Commit:     Dave Airlie <airlied@redhat.com>
CommitDate: Fri Jun 16 11:19:34 2023 +1000

    This seems to have existed for ever but is now more apparant after
    commit 9bff18d ("drm/ttm: use per BO cleanup workers")

    My analysis: two threads are running, one in the irq signalling the
    fence, in dma_fence_signal_timestamp_locked, it has done the
    DMA_FENCE_FLAG_SIGNALLED_BIT setting, but hasn't yet reached the
    callbacks.

    The second thread in nouveau_cli_work_ready, where it sees the fence is
    signalled, so then puts the fence, cleanups the object and frees the
    work item, which contains the callback.

    Thread one goes again and tries to call the callback and causes the
    use-after-free.

    Proposed fix: lock the fence signalled check in nouveau_cli_work_ready,
    so either the callbacks are done or the memory is freed.

    Reviewed-by: Karol Herbst <kherbst@redhat.com>
    Fixes: 11e451e ("drm/nouveau: remove fence wait code from deferred client work handler")
    Cc: stable@vger.kernel.org
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Link: https://lore.kernel.org/dri-devel/20230615024008.1600281-1-airlied@gmail.com/

Signed-off-by: Mika Penttilä <mpenttil@redhat.com>

Author: Mika Penttilä

drivers/gpu/drm/nouveau/nouveau_drm.c

@@ -137,10 +137,16 @@ nouveau_name(struct drm_device *dev)
 static inline bool
 nouveau_cli_work_ready(struct dma_fence *fence)
 {
-	if (!dma_fence_is_signaled(fence))
-		return false;
-	dma_fence_put(fence);
-	return true;
+	bool ret = true;
+
+	spin_lock_irq(fence->lock);
+	if (!dma_fence_is_signaled_locked(fence))
+		ret = false;
+	spin_unlock_irq(fence->lock);
+
+	if (ret == true)
+		dma_fence_put(fence);
+	return ret;
 }
 
 static void