Skip to content

Commit

Permalink
nouveau: fix client work fence deletion race
Browse files Browse the repository at this point in the history
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/
  • Loading branch information
airlied committed Jun 16, 2023
1 parent c8ac109 commit c8a5d5e
Showing 1 changed file with 10 additions and 4 deletions.
14 changes: 10 additions & 4 deletions drivers/gpu/drm/nouveau/nouveau_drm.c
Expand Up @@ -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
Expand Down

0 comments on commit c8a5d5e

Please sign in to comment.