[PATCH] drm/nouveau: Clear fence channel in no-signaling path

[PATCH] drm/nouveau: Clear fence channel in no-signaling path

[Beomseok Kim]

nouveau_fence_signal() clears fence->channel before dropping its
reference.  nouveau_fence_no_signaling(), however, removes an already
signaled fence from fctx->pending without clearing the pointer.

The fence can remain attached to a BO reservation object and be used
later in nouveau_fence_sync() after channel teardown has freed the
channel.  This leaves a stale channel pointer that the sync path can
dereference.

A diagnostic build with concurrent short-lived Wayland GL clients
observed nouveau_fence_no_signaling() with a fence pointing to channel
C, nouveau_channel_del(C) returning, and then nouveau_fence_sync()
attempting to read C->cli.  A no-fault read failed after teardown.

Clear the pointer in nouveau_fence_no_signaling() to match
nouveau_fence_signal(), so the sync path uses the fence wait fallback.

Fixes: 29ba89b2371d ("drm/nouveau: rework to new fence interface")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Beomseok Kim <dilddream31@gmail.com>
---
 drivers/gpu/drm/nouveau/nouveau_fence.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c
index edbe9e08b..5b09cf134 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -488,6 +488,7 @@ static bool nouveau_fence_no_signaling(struct dma_fence *f)
 	 */
 	if (nouveau_fence_is_signaled(f)) {
 		list_del(&fence->head);
+		rcu_assign_pointer(fence->channel, NULL);
 
 		dma_fence_put(&fence->base);
 		return false;
-- 
2.55.0