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: [email protected]
Assisted-by: LLM
Signed-off-by: Beomseok Kim <[email protected]>
---
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
