Re: kern/58745 (nouveau triggered assert in linux_dma_fence.c)

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

Attached patch works around it.  On the fence about whether to commit
this (and introduce another local diff) or just relax the assertion.

# HG changeset patch
# User Taylor R Campbell <riastradh%NetBSD.org@localhost>
# Date 1728700032 0
#      Sat Oct 12 02:27:12 2024 +0000
# Branch trunk
# Node ID 8465cbb178fcac2a01a66c33646eb41f7b497283
# Parent  94b69b01d60e6b02d6aefbbb562c511991aba09f
# EXP-Topic riastradh-pr58745-nvfencechanerr
nouveau: Don't set dma fence error if already signaled.

This happens asynchronously on hardware error.  Upstream Linux trips
WARN_ON in this case; our dma_fence_set_error trips KASSERT instead.
We could maybe switch dma_fence_set_error to use WARN_ON too but it's
probably better not to take this path anyway -- this assertion trips
on logic that is incoherent, if not outright wrong.

PR kern/58745: nouveau triggered assert in linux_dma_fence.c

diff -r 94b69b01d60e -r 8465cbb178fc sys/external/bsd/drm2/dist/drm/nouveau/nouveau_fence.c
--- a/sys/external/bsd/drm2/dist/drm/nouveau/nouveau_fence.c	Thu Oct 10 21:42:24 2024 +0000
+++ b/sys/external/bsd/drm2/dist/drm/nouveau/nouveau_fence.c	Sat Oct 12 02:27:12 2024 +0000
@@ -102,7 +102,7 @@ nouveau_fence_context_kill(struct nouvea
 	while (!list_empty(&fctx->pending)) {
 		fence = list_entry(fctx->pending.next, typeof(*fence), head);
 
-		if (error)
+		if (error && !dma_fence_is_signaled_locked(&fence->base))
 			dma_fence_set_error(&fence->base, error);
 
 		if (nouveau_fence_signal(fence))