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

[Marek Czernohous <mczernohous@gmail.com>]

On Mon, 28 Sep 2026 17:14:50 +0900, Beomseok Kim <dilddream31@gmail.com> wrote:
> 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.

[...]

> @@ -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);

I think this patch fixes drm/nouveau#443 [1]. The nouveau_fence_sync()
oopses there and in the reporter's thread [2] (MCP79, Debian 6.12.43,
6.12.90 and 7.0.10) all fault at CR2 0x40 on the prev->cli->drm load,
with prev taken from f->channel and prev->cli NULL. A channel's cli is
never cleared, so prev most likely points to a freed channel. That is
the stale pointer described above: the no-signaling path is the only
way off fctx->pending that leaves fence->channel set, and
nouveau_fence_context_kill() only walks fctx->pending.

The fix looks right to me. enable_signaling runs under the fence lock
(&fctx->lock) while the fence is still on fctx->pending, so the new
store happens before nouveau_fence_context_kill() takes that lock, and
thus before the synchronize_rcu() in nouveau_fence_context_del(). With
fence->channel NULL, nouveau_fence_sync() falls back to dma_fence_wait()
on an already signaled fence.

Emmanuel Fleury's prev->cli check for the same oops [3] only helps when
the freed memory reads back as zero, so I prefer this patch.

The patch applies to 6.12.y with an offset; compile-tested there with
W=1 only. I have asked the reporter (Cc'd) to test it.

I did this review with help from Claude (claude-opus-5-5).

Reviewed-by: Marek Czernohous <marek@czernohous.de>

[1] https://gitlab.freedesktop.org/drm/nouveau/-/issues/443
[2] https://lore.freedesktop.org/nouveau/b7f523dc-fe41-4514-a1a5-747005311cbe@yahoo.fr/
[3] https://lore.freedesktop.org/nouveau/1690ea65-a1e0-4a34-bde1-bdd26e31c6c4@u-bordeaux.fr/