From nobody Wed Sep 30 05:01:07 2026 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 727A747012F for ; Wed, 12 Aug 2026 23:13:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786576417; cv=none; b=ZL+Xp4Y2poAwRN1wpSh0r6Ra0zxB+rqAFT9XPkYhzObdMUNKns+SFLm3ZgyTwArD9TAScYV0pVBLOw1ugeXKrvNqs1psF43BEnxBMHlfFkpKFoLdlp7TvrlICqsMrKAsSTC57XMGAJMhiw6q0VdbQ+NYOcd4xFj0DmMWoMqE4Og= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786576417; c=relaxed/simple; bh=TC/Xzr2z2LXiSDb6I+9W0aw4iSzSEPX8CBnDpuBex/k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=r19O9PrS7/eMSAjMZrmgp30ew4cmETKp+p6dZ6nTcx7w8KxVOIKTYxKhKKoO9sCzWR5ImB0XTiV+Duj9bo0ryEn5eSUy1aQCSARXKFGR/BybI0I4ULy2H9+0EQd3MHsXT66op86JWnSqGz/hj/Xw9Ua23QsxFDqvPwKIdfACgCc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=T0kssy4z; arc=none smtp.client-ip=209.85.128.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="T0kssy4z" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4954b3c5cbeso1341015e9.1 for ; Wed, 12 Aug 2026 16:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786576414; x=1787181214; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=AEqCe/HJ702G2+cOJ6AJfXRuzYV9ZGHajSHLyVpChGo=; b=T0kssy4zWZKOZ/QBpgjkJFNhrq4l7t1tm9lhrNPqfNH/SVUXKtcEbVIp64tHSmgpzz v5efFB5XhrD4gHaRYl4DdvuKZL71VTf8/VaX8+Gv4UGLPq+K2btYmgShJwkfwvnFYvNQ n118v4ngZW8nH4o/ZopQ4FQatnGtKkprg07ZOo5T+lHTFXCSEqDHBqyYtFuQ3iWlxBJ8 l5b/uMkwBOqIWyVcnlkxRU0ePZta+olXN4QFmM/tr94tp5uwxijiUIsL+OEerlDJqfKI R1GXgkkmCmN/LOgEZePQ/ve3ei4ZvOmgm5N+2aJ1zfbn78+Yigjn7BJ6XoRbJZfsgHso 7PMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786576414; x=1787181214; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=AEqCe/HJ702G2+cOJ6AJfXRuzYV9ZGHajSHLyVpChGo=; b=qoylDPJ8o7WcBOCvMYGEPpyJqM+EBqEWOye25RbNhkM35qpDAAgCfQo1H2HPNaDZ36 YOKluwv/c6XAmVykBbcLQ2hBFHO9y/30fMgkClDcX4VuBMcHIryORF9SoKNZyOYIs+4N L4tOJyqnyZ54FsTO1ErF3ABEI+8jVHVAVonNPA+H/B4n7g9+Z3Re8/JTxXd00eHXwnUY Oj9lWlya2RURgbYOlWrtLUcW6LV1i+0hSFgSVRrPDRXDZ2qXPXo3e/Cgcq+tXJT3Bome vzadKC89CMwsszQwkSs5g2MNB1+cbd67YuunhVBZTl0QlsNMd3IZ1yBYXwanERn42IBL D4Cw== X-Gm-Message-State: AOJu0YxTUy1+c0NmAZGQ/ra6wRWiTGEMbF+nAohKVTZuKzBuiNLYSd49 7pK6Wtp+eGAntH2o4LtmRnYzVF3wE9ceSmIgWD1ppBc66xGXsEArr1vy X-Gm-Gg: AR+sD10+tpWeFnNeUjdqtQm9kuyoaTtJkpDeU7sSJBQOA6yxs0iCEjrfYzhopDFyMQj TCBfd6+G7z1WdrkaXqPTjgFOOJLV4NB1ahd2OXyXkDYj8MKrc8c2iTm/5+7dDWh8KHf6mAlnrNE +2+jpZNaK0F5AOZvKvlXtZZjt/7gEJSEEw+zN0j2xYJOVsYYp6EfMkCnAWI/icjH3itBuz8Li1f oyOs8hexiAgm6pZzFF4kwJj8CTOForcpfIK+/hPA05Xx3GW6gvyAs5uxqKvMCQyJsFoUo0TGPVb gKot3kvPDtkZ0Rq92GP5pswVkajJilUzamP33vayY9eXaeQdp97uR3dqduYHyEfX1ZDGQzFwBgs 24JceVboJH+4wWMOnSsCubPcbsUtyDrsICAhrkjq6HNlH6MxNrucFwaaP9+qctiGlYjjmH7cEch TvD8OdyXeQbqsrpSnPeaBgRv7I7oECH4cyl3oc6DXb1Mw1sCftad8OU5el4kxioGlaAlTUuKRoj cVR9GFgUDERNUTYdo6ImBQGVArwFed4HEp4jAn7Eq5JOIkE5zQ2d0y7QS4lLkpfbQ== X-Received: by 2002:a05:600c:a05:b0:495:7561:a9cc with SMTP id 5b1f17b1804b1-499821e762dmr6690785e9.4.1786576413605; Wed, 12 Aug 2026 16:13:33 -0700 (PDT) Received: from Neo.taile6b6ba.ts.net (ip-109-193-028-127.um39.pools.vodafone-ip.de. [109.193.28.127]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49981b631c1sm44532245e9.14.2026.08.12.16.13.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Aug 2026 16:13:33 -0700 (PDT) From: Marek Czernohous To: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org, Danilo Krummrich , Lyude Paul , David Airlie , Simona Vetter , Ben Skeggs Subject: [PATCH v3 1/4] drm/nouveau: unsubscribe the channel-kill event before the fence context Date: Thu, 13 Aug 2026 01:13:27 +0200 Message-ID: <20260812231330.705425-2-mczernohous@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260812231330.705425-1-mczernohous@gmail.com> References: <20260812231330.705425-1-mczernohous@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Marek Czernohous nouveau_channel_del() tears the fence context down first and only drops the channel-kill subscription later, in the middle of the nvif object teardown: if (chan->fence) nouveau_fence(chan->cli->drm)->context_del(chan); ... nvif_object_dtor(&chan->vram); nvif_event_dtor(&chan->kill); The subscribed handler is nouveau_channel_killed(), which calls nouveau_channel_kill() and from there nouveau_fence_context_kill() on chan->fence. A kill event delivered in that window takes fctx->lock and walks fctx->pending on a fence context that context_del() has already freed. Nothing reaches this below Fermi today, because the subscription is gated on FERMI_CHANNEL_GPFIFO and nothing kills a channel there. On Fermi and newer the window is real but narrow, since a kill has to land exactly while the channel is being destroyed. That is reason enough on its own, which is why this carries a Fixes: tag. The last patch in this series subscribes Tesla channels as well; nothing kills those today, so it does not widen the exposure now, but it is the groundwork for a recovery path that would, and the ordering is better fixed before that lands than alongside it. Drop the subscription before anything it depends on is torn down. Fixes: ea13e5abf807 ("drm/nouveau: signal pending fences when channel has b= een killed") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Marek Czernohous Reviewed-by: Lyude Paul --- drivers/gpu/drm/nouveau/nouveau_chan.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c b/drivers/gpu/drm/nouve= au/nouveau_chan.c index 598513f60449..f142f6310596 100644 --- a/drivers/gpu/drm/nouveau/nouveau_chan.c +++ b/drivers/gpu/drm/nouveau/nouveau_chan.c @@ -90,6 +90,14 @@ nouveau_channel_del(struct nouveau_channel **pchan) { struct nouveau_channel *chan =3D *pchan; if (chan) { + /* + * Drop the kill-event subscription first. Its handler + * dereferences chan->fence, which the fence context teardown + * below frees, so leaving it armed across the teardown leaves + * a window for a use-after-free. + */ + nvif_event_dtor(&chan->kill); + if (chan->fence) nouveau_fence(chan->cli->drm)->context_del(chan); =20 @@ -100,7 +108,6 @@ nouveau_channel_del(struct nouveau_channel **pchan) nvif_object_dtor(&chan->nvsw); nvif_object_dtor(&chan->gart); nvif_object_dtor(&chan->vram); - nvif_event_dtor(&chan->kill); nvif_object_dtor(&chan->user); nvif_mem_dtor(&chan->mem_userd); nouveau_vma_del(&chan->sema.vma); --=20 2.54.0 From nobody Wed Sep 30 05:01:07 2026 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 194FC49505F for ; Wed, 12 Aug 2026 23:13:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786576418; cv=none; b=qITh/sD67o8aUtKEQhrA56mMJ4qRdh83eHi6+HW2y3KoRvNt/TbZfbRfQWu6l3StHmXJdxvSQMjbt7WO/hCXt+JyvK1/dGIme10wegFLQS7TvlQYe5Q9pjtWIvrznFG4TwjVPRhw1T5XpWSjnIovDxdQOOiJXQwpNjt0GrI3ooc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786576418; c=relaxed/simple; bh=K1T094YKiTFXwLhyddi87t2RcNlrJTOzphdlDYjsXIQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=W1K8VEUhxyRmAra80wp6lyMKl+xcrPtq76llLh/u9m7tFmjeOo1Y8EDS2eBR6clL0tpCSketzfNQmfZIn5nSU1JyulFAOIoF+yt+QRYRCG/C6cliyZqxyz/57rLcVQvDq5aeKAwy5V3n4D+kVWzfM0yTpHp8iNtOqwBvdi6eHyI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=s84DD9aG; arc=none smtp.client-ip=209.85.128.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="s84DD9aG" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4957799b92fso1195265e9.1 for ; Wed, 12 Aug 2026 16:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786576415; x=1787181215; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=b4ewDgBabacjDaP8NBVKD5QYsXGYuSL6SciAIvMhBJc=; b=s84DD9aGl3xrNz2TRpHjjEJIUvT6eDn3CJGzysq8+7sAkRRBCKcAwmVG8UyetbuHM2 yTj0B9tRREJtRMvU1ZzE56kYSy7rWuF35ECtu8YObO5XlXk0DWT6nj4Useq5lte510To 4wxApr7fwdPEfp+usKIz3VclgN1LYaD805/pPrOgI9DtFyK5XqewqH0aukg/Nxjd1h+n HIUC2qMwctvqv3lkCyqYXoSmZoJfIwMHCFzInD9N2EO9ovwRXeRWVBRIL761Gjnh0H0F aUw3bM2p/OM7iY3VCcS1b/lSZF6dyQ4Nup40yN23wtZKZvJ7IIooSfvN7Naol2D2MvXS gUBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786576415; x=1787181215; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=b4ewDgBabacjDaP8NBVKD5QYsXGYuSL6SciAIvMhBJc=; b=VYIEUgGlA+tJobJ4rsfCNObzo7yw12XvH9Sfym9I7NbASD0ziHAcpsGw2yvtwFM4pV 0D/QW338nFPjVyvnd/++6JlEgpL+3zZqpfWXvG+F0Q3WKA0NAb8/3UAwWBbWPJr4Y29s qS21ufivKVS0qEzC/n2wvALkAKYYx3/Q68s/XoOeYJ4WRWfXEicT7mRglGtYPSuPdtJb 6A4VwwYI460g5kwnGYT5sYueRPH6jAsmmpmFTwp3T2l2j3Zr7SOcxMjdybl9uDBMbLmw vKWx84etFrpL9F7XzycmWHirPtpoupySdq2+JdZatqNMmLv6kE1G9+8XMLM49fd7PQmx LMTg== X-Gm-Message-State: AOJu0YxEs+5Youj27G3/G0XdzF1UEfI6JY1KXoVtlk3bCndeOnY3F1WW AXioTdm0ud0E5Pfy5WCBI1RJWDvzsj17mY6vSrRfjpHSU/fgNWYsUI1L4wJFNjSa X-Gm-Gg: AR+sD10mYgKj4CiVV9c73R9VEppaIB/bucBccBcL+plmZd5PE4zBqywp2O85sBvrKzK neLHEe8umR1XoHVjsD6qvaWkDPGl3XRJoghwf1+da2Hg5IDYeNi1TKqdpHN5hRh2o1DkhPmN04M 5lSApzdjzsAFDL0pEEKm76WyeGkG3opebtfdhgHootiETHA6+lVIEUK57aCZnhUyDugV9x+gLKs M4gYTY1BFyF/wln9I3dDFEyCM8KcXaXy18L/SsPpAaukS08VMjYVQOHUqdhRqzIm7csmW3zQoI2 S0WghpoIWvvB1fqfG4R+kao+Yv+ay8JBm3KriqDIN1ApHMpLTSuH0XyV4P+tJW5lAATC60ufuVR a/hlRhyYTgwlOE+1Wx0D5XS2sKStMr0tYcj+Ydb1gc+XkmQ6k3uV+OtpH48rxn26CpEz01bjHnQ r4D8UBUS6Vx5ITdaaMTR4SejqT7GmsFKtTvX1zsk1jQ9n5sgamgAv0UMBPKA/9G+qlcojdrilnw 1GQIdQeYZTrxd6Q5G2nP8bGjQZV1yIh5Z325WsRN/+rFHH2m/BR8aQ= X-Received: by 2002:a05:600c:e547:20b0:499:4d41:cd13 with SMTP id 5b1f17b1804b1-4998212ee6amr4162105e9.0.1786576415303; Wed, 12 Aug 2026 16:13:35 -0700 (PDT) Received: from Neo.taile6b6ba.ts.net (ip-109-193-028-127.um39.pools.vodafone-ip.de. [109.193.28.127]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49981b631c1sm44532245e9.14.2026.08.12.16.13.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Aug 2026 16:13:34 -0700 (PDT) From: Marek Czernohous To: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org, Danilo Krummrich , Lyude Paul , David Airlie , Simona Vetter , Ben Skeggs Subject: [PATCH v3 2/4] drm/nouveau: subscribe to the channel-kill event after the fence context Date: Thu, 13 Aug 2026 01:13:28 +0200 Message-ID: <20260812231330.705425-3-mczernohous@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260812231330.705425-1-mczernohous@gmail.com> References: <20260812231330.705425-1-mczernohous@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Marek Czernohous nouveau_channel_init() arms the channel-kill subscription early, right after mapping userd, and only creates the fence context at the very end of the same function. The handler it installs, nouveau_channel_killed(), reaches nouveau_fence_context_kill(chan->fence). The NULL check in nouveau_channel_kill() does not cover the window in between. The backends publish the pointer before the context is usable: fctx =3D chan->fence =3D kzalloc_obj(*fctx); if (!fctx) return -ENOMEM; nouveau_fence_context_new(chan, &fctx->base); and nouveau_fence_context_new() is what runs spin_lock_init(&fctx->lock) and INIT_LIST_HEAD(&fctx->pending). An event arriving after the assignment but before that call finds chan->fence non-NULL and unusable: nouveau_fence_context_kill() takes a lock that was never initialised and walks a list head whose next pointer is still the NULL left by kzalloc(). Move the subscription behind context_new() so the handler cannot observe a half-built fence context. The failure path is unchanged in effect: the caller drops the channel with nouveau_channel_del() either way, which since the previous patch unsubscribes before freeing the context. One behavioural change worth naming, and it is not free: a kill delivered while the channel is still initialising is no longer observed, because the subscription is not armed yet. That window does not close here, it moves, and on Fermi and newer it grows by the span between the old subscription point and context_new(). What changes is what the window costs. Before, a kill landing in it reached a half-built fence context; now it is missed, and the channel is left blocked with chan->killed still 0, so nouveau_channel_idle() and the checks in nouveau_gem_ioctl_pushbuf() and nouveau_exec_ioctl_exec() keep treating it as alive. The missed-kill window is not introduced by this patch either: nvkm_uchan_init() already calls nvkm_chan_allow() and nvkm_chan_insert(), so the channel is schedulable before nouveau_channel_init() subscribes at all. Closing it properly means subscribing before the channel becomes schedulable, which is a bigger change than this fix. As with the previous patch this is unreachable below Fermi today, and the last patch in this series lowers the gate to NV50. Fixes: ea13e5abf807 ("drm/nouveau: signal pending fences when channel has b= een killed") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Marek Czernohous --- drivers/gpu/drm/nouveau/nouveau_chan.c | 55 +++++++++++++++----------- 1 file changed, 33 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c b/drivers/gpu/drm/nouve= au/nouveau_chan.c index f142f6310596..07b0bd1bc519 100644 --- a/drivers/gpu/drm/nouveau/nouveau_chan.c +++ b/drivers/gpu/drm/nouveau/nouveau_chan.c @@ -370,27 +370,6 @@ nouveau_channel_init(struct nouveau_channel *chan, u32= vram, u32 gart) if (ret) return ret; =20 - if (chan->user.oclass >=3D FERMI_CHANNEL_GPFIFO) { - DEFINE_RAW_FLEX(struct nvif_event_v0, args, data, - sizeof(struct nvif_chan_event_v0)); - struct nvif_chan_event_v0 *host =3D - (struct nvif_chan_event_v0 *)args->data; - - host->version =3D 0; - host->type =3D NVIF_CHAN_EVENT_V0_KILLED; - - ret =3D nvif_event_ctor(&chan->user, "abi16ChanKilled", chan->chid, - nouveau_channel_killed, false, - args, __struct_size(args), &chan->kill); - if (ret =3D=3D 0) - ret =3D nvif_event_allow(&chan->kill); - if (ret) { - NV_ERROR(drm, "Failed to request channel kill " - "notification: %d\n", ret); - return ret; - } - } - /* allocate dma objects to cover all allowed vram, and gart */ if (device->info.family < NV_DEVICE_INFO_V0_FERMI) { if (device->info.family >=3D NV_DEVICE_INFO_V0_TESLA) { @@ -494,7 +473,39 @@ nouveau_channel_init(struct nouveau_channel *chan, u32= vram, u32 gart) } =20 /* initialise synchronisation */ - return nouveau_fence(drm)->context_new(chan); + ret =3D nouveau_fence(drm)->context_new(chan); + if (ret) + return ret; + + /* + * Subscribe to the channel-kill event last. The handler + * dereferences chan->fence, and the fence context is only complete + * once context_new() has returned: the backends assign chan->fence + * from kzalloc() before nouveau_fence_context_new() initialises the + * lock and the pending list, so an event arriving in between would + * find a non-NULL but unusable context and walk a NULL list head. + */ + if (chan->user.oclass >=3D FERMI_CHANNEL_GPFIFO) { + DEFINE_RAW_FLEX(struct nvif_event_v0, args, data, + sizeof(struct nvif_chan_event_v0)); + struct nvif_chan_event_v0 *host =3D + (struct nvif_chan_event_v0 *)args->data; + + host->version =3D 0; + host->type =3D NVIF_CHAN_EVENT_V0_KILLED; + + ret =3D nvif_event_ctor(&chan->user, "abi16ChanKilled", chan->chid, + nouveau_channel_killed, false, + args, __struct_size(args), &chan->kill); + if (ret =3D=3D 0) + ret =3D nvif_event_allow(&chan->kill); + if (ret) { + NV_ERROR(drm, "Failed to request channel kill notification: %d\n", ret); + return ret; + } + } + + return 0; } =20 int --=20 2.54.0 From nobody Wed Sep 30 05:01:07 2026 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 26B0A4963A4 for ; Wed, 12 Aug 2026 23:13:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786576419; cv=none; b=U5dhHSOPcClETXqTVcKLZ+O0xacCfcDWusQ1+Pvd/2rpEA1NFj4M+q3ZsGpI0OXuz0hFId7JQ1396P/5CyrFM+FXAYDSveVuyMQFPo9qH3V40tAilAbsj5ODn4KM3+Hget0s3eB2K510ls7zPhJSDqVK4Q8plfjJvIYKVYUC4G8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786576419; c=relaxed/simple; bh=FZQz+7OWFHg94dNQrOsWFBp+5R7syyPQvIJQ3cZBa3k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pYz1TMA+ic2mK+04Wlk6WPxRtr+5a7xM13LdUiEnDxSUg35NoTsNrRSLvxo1bKLrhTzSjVdPC5hB6btv8qO0VRHTCUdV7hGpnmVEF7Izy8gr6cmb3X0QW90W4kNF7BwY1loES8J/lJ4mYnVsemrxyDOHPKeUJCYppKtuZzS6Ba8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=LmFXzvXH; arc=none smtp.client-ip=209.85.128.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="LmFXzvXH" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4956d1d9fb2so1348185e9.0 for ; Wed, 12 Aug 2026 16:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786576416; x=1787181216; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Tfw6HroNHGc2c12iMbCQTsQpKK1xWyV/VLQvyFAcyJg=; b=LmFXzvXHcXs5quK4TWRVOWDjz0zbZi/CkWOZNSwm7jXmooUgDr5UAK59ljSoBu9uUw MJ71Si+Suxx8RHieV5hxshnSkyyyOK8IGlv4fP7QeuaRcRlcxkLwzUNMDVFrwfSrK/O7 a3jLVVAhwdkSUGdRmz64eUHqwyhdzG+asndPYzZTYcw9xnYMaUa45qDyAITSbIdOO1B0 a77hKWlPVeWoW9oaEtas7GgpBmQdLdZ6ARm/VNqDAPdYEeKGVsFaiXX/BPSXON0F4Ul6 UlCLN9k47OuZdn3ruduSR8GxeAPKQbZGAJVgNX6Z79OzeY7dqzBnWc85EKYtSv3XOVlo mFwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786576416; x=1787181216; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=Tfw6HroNHGc2c12iMbCQTsQpKK1xWyV/VLQvyFAcyJg=; b=VvPqYP/knlPxB2gexgrCVNWhrV8gV/AlVZn1A5+YHRWUIDpamkv5xr1PFg83+phq8w Hh5nFnfxQlwbt+XDKm3ZBjLfzZyHLgrlIfpmqJHg31Tsa+vtItscg1YapQBO3y8aHDK6 IYWpIkHLOQ0pUvrNdN3U1EBc6oIiEgizHJg3T5w4dhJL2RTehvOVSy9ltkDh9Vz3+vCH fxlVBsg5eIOoJFtsNqQwI2nOfgoa5rKjRNgbHtP1m88lIgIA4jTrGPi5Fe71JtTvMqi+ 1cbr6GPnb1k0qc6HSabX2J8La/TzVqWyu4o1OgsPwKpqrGK2B42CXwtHC0wr67HFZu0h ZxUQ== X-Gm-Message-State: AOJu0YyPxteZE5EwsQsCcRpMI7NI1W8w66dI5qWbbRH3pfF/CxaG7Jwe H2xHN4WuIkItbj2uMoeSFVzo+Wl3m9mBnDrd6YxrbmZqBz3BvF4tEYqI X-Gm-Gg: AR+sD10kQp3vZXpYrWjFqDtojWisuKslVeawiXdkK3V0w+EBeAtYuoJb8SJIzNHvSxf tkBQTZWciJLlqO2Px5hPvHzBKwdRw/+uZmn6PJOJaCfUWn3UvCECHddQcSARancEC4WqebyTJvh IdSx7ewDsd01NUvogQ4B+QLPP/De/ZZwHL8zQ7yGZB4AvhUOI2Nzl1bKE/u8bUEAe9QCfFcpzoo oq9fbh7ji/jdnAKofcgo7vEmCWxJvA68Isw5JteWonVx9GZDvjcAQUI4RP8E7bN1hgdTvYzKVtC NxotEXcjYNbIFiJfHqwpIezBqFVHPUVVoGWsKQSdx2KrrcY11RF8j6sDsjhRC1onnEkkmU8XRCW FQYUArM0nyRkd5OkOeaoy+ufFmDe1ZwUFTU+W55hShMmBSyY0p4pTuIIYsLOicmadvXb6kVVZP+ GjQgirabiQAXH2iuUKR0sCEq2Vd/nw7xGf1i211EVNqTY1N0MXFOHbbRz1+GSabZVQB9seVrOIF LXbUNnk578ugx0FuTj0JlFpQBVUzuOd7VFr+VdhY5OqL5UrblPvb7o= X-Received: by 2002:a05:600c:3b2a:b0:495:4505:dad0 with SMTP id 5b1f17b1804b1-499821ad33cmr5870475e9.2.1786576416271; Wed, 12 Aug 2026 16:13:36 -0700 (PDT) Received: from Neo.taile6b6ba.ts.net (ip-109-193-028-127.um39.pools.vodafone-ip.de. [109.193.28.127]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49981b631c1sm44532245e9.14.2026.08.12.16.13.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Aug 2026 16:13:35 -0700 (PDT) From: Marek Czernohous To: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org, Danilo Krummrich , Lyude Paul , David Airlie , Simona Vetter , Ben Skeggs Subject: [PATCH v3 3/4] drm/nouveau/fifo/nv04: filter benign CACHE_ERROR from Mesa NV50 bind probe Date: Thu, 13 Aug 2026 01:13:29 +0200 Message-ID: <20260812231330.705425-4-mczernohous@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260812231330.705425-1-mczernohous@gmail.com> References: <20260812231330.705425-1-mczernohous@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Marek Czernohous The Mesa userspace driver issues a method-0x0060 / data-0xbeef02xx binding probe that ends up triggering CACHE_ERROR in the PFIFO interrupt handler. The probe is harmless and recovers cleanly, but it is reported at error level, so it shows up in dmesg on session start. Filter that specific pattern down to debug level so dmesg stays clean while real CACHE_ERROR conditions are still logged at error level. The test is on the method and data pattern alone, not on the chip family, so it applies wherever nv04_fifo_intr() is the handler, that is nv04 through g98. That is deliberate rather than an oversight: a false positive would need userspace to write exactly 0xbeef02xx to method 0x0060, and the probe itself comes from the shared nouveau Gallium code rather than from anything NV50 specific. Say so here so the narrower wording of the subject is not read as a chip gate. Evidence: 99 occurrences across three logs from a second, independent MCP79/MCP7A machine running 7.0.10 and 6.12.90, under both Xorg and Wayland, with kwin and plasmashell named as the faulting clients. On my own reference machine the filter went in before the persistent kernel log did, so I cannot show a clean before and after from there. Assisted-by: Claude:claude-opus-5 Signed-off-by: Marek Czernohous --- .../gpu/drm/nouveau/nvkm/engine/fifo/nv04.c | 26 ++++++++++++++----- 1 file changed, 20 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv04.c b/drivers/gpu/= drm/nouveau/nvkm/engine/fifo/nv04.c index c4b8e567d86f..ab144c1bd9da 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv04.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv04.c @@ -327,12 +327,26 @@ nv04_fifo_intr_cache_error(struct nvkm_fifo *fifo, u3= 2 chid, u32 get) =20 if (!(pull0 & 0x00000100) || !nv04_fifo_swmthd(device, chid, mthd, data)) { - chan =3D nvkm_chan_get_chid(&fifo->engine, chid, &flags); - nvkm_error(subdev, "CACHE_ERROR - " - "ch %d [%s] subc %d mthd %04x data %08x\n", - chid, chan ? chan->name : "unknown", - (mthd >> 13) & 7, mthd & 0x1ffc, data); - nvkm_chan_put(&chan, flags); + /* + * Filter the benign Mesa bind probe: mthd 0x0060 with data + * 0xbeef02xx is a harmless userspace probe and does not + * indicate an actual error condition. The test is on the + * method and data pattern alone, so it applies on every + * chip that reaches this handler, not just on Tesla. + * Demote to debug to keep dmesg clean while still catching + * real CACHE_ERROR events. + */ + if ((mthd & 0x1ffc) =3D=3D 0x0060 && + (data & 0xffffff00) =3D=3D 0xbeef0200) { + nvkm_debug(subdev, "CACHE_ERROR - ch %d subc %d mthd %04x data %08x (be= nign, skipped)\n", + chid, (mthd >> 13) & 7, mthd & 0x1ffc, data); + } else { + chan =3D nvkm_chan_get_chid(&fifo->engine, chid, &flags); + nvkm_error(subdev, "CACHE_ERROR - ch %d [%s] subc %d mthd %04x data %08= x\n", + chid, chan ? chan->name : "unknown", + (mthd >> 13) & 7, mthd & 0x1ffc, data); + nvkm_chan_put(&chan, flags); + } } =20 nvkm_wr32(device, NV04_PFIFO_CACHE1_DMA_PUSH, 0); --=20 2.54.0 From nobody Wed Sep 30 05:01:07 2026 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 18F9A4963C3 for ; Wed, 12 Aug 2026 23:13:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.53 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786576420; cv=none; b=BEoiXH2iCGcAj2deFi7NK2v/WHf4em2hPhJpF4ZvIy7bap+v6Cx6XLEoy3jVPNhsepm0NW0NzQdB67gqZa9lC7YIC7znTrzLWo+yMTnq/hz6axoMywwZiRR/PlcdSbn7XPZpiTlxeIBJRRbe7+40CYSJnp6SMHLpq+6fm7UmSxI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786576420; c=relaxed/simple; bh=I3WhJWLbx+mUMI83DKiCaZ/4Pz5Am1rpp/LVNrugUBI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TxRy9fytYeSWNrTu2osbGFAke78YxagT/msBaY5gXnryRkVXapIpRWxgTd4uMi/5GRkV8gLDYpaTjv3k8f6fl+IhbZejx9OMKUE82u35/36NA/UJznTldc5eloozsP/e+Q44hG7OgkoyULrzh68BXBnogqBf5QP5a7JRuqAIZFg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=XoP1y8Jm; arc=none smtp.client-ip=209.85.221.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="XoP1y8Jm" Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-4731f5ffa74so87349f8f.1 for ; Wed, 12 Aug 2026 16:13:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786576417; x=1787181217; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Z565EJ0GnjhReuEzH6bow6YJdlk7vm6R+vte4T3cg/Q=; b=XoP1y8JmaR19JaGy1adRugpv6j12oePfVQxm4bD+i4sLcxZctwL1HZuMzjklqvxtBz 3VZEsjjaLTM7ewdpIFsxSy9eCyczSSW4eSgUkVFHCqgwMeVwITjIB3LZWI73Sutrw0GU HtMuucOiMKhegoxPu2qYnErlGIQTeQUiPGp1xrGUqYwWYmFMxoPRJ4GTcrt5ViD944Qd +2eA/owoQd5GHFCFtgcg8gUJy9sc9jG/UfcCkWCTFbZKjAj5Sqzo895x7OLQZN/jQMzj 8XOjSefO3Y/IVgN4opElrAMHumRk7Yyyo3fajj4GVGkfOrFd71SAkGP8LiGCxHyR6MEq /DRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786576417; x=1787181217; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=Z565EJ0GnjhReuEzH6bow6YJdlk7vm6R+vte4T3cg/Q=; b=eFUcp1KODVQ0tmAsTBAYbuJKh0VDWVK2eyL4v+XHcNc4h1tu60ZcI12t8C1D2FRqiX 3VH5jHEwT9qarrMohICAdfnPUWdxlYWSBzfmTOwhc40ZJPcxrPpdIzdbvzngGIkzdWGc uNCT01W+x3DHzK/JG6AuepP1c7zIwIEZi5Sg/Yk5Ww+JyEmDNplBFcpJIUZDCWLPVqZ3 uBlkNormhqjzWNIg99SetwgwQxp3lCmLWx4cSGqzG7qu85byAsxlzRpxKFVLQUT/63t5 goyl6VMTl7nwFYujOTp3/yVYkRdqFBGSVOcEnbE/y8lkpTivfrx+ef8ktQeKnHfzO8/X qmGw== X-Gm-Message-State: AOJu0Yw/Hh21HEj40HpCqipWJaIDRnAeMm7RBIMmrEiuzrOEpMghYo+v 4Mk9Kxr5xuFGu86WVtsUWnQNx2kkBjV8zpiiUPEFElPeqFQ/PZcmPAWtVtq6ZZOG X-Gm-Gg: AR+sD11C94h8bqyMIS3qd0/B5RkSbwNy7f7skr1yYk91f3Hzcw9oiJTBvsHHE7Li8Ju ZcJMhv0f0HEKGmnVhrihmmgMYNPdnBH5BTkSv+QSE4ct+OHH7+iKeeT0j1VmAqqmwJJo6VsE8EI GR9SadAOUMTu3mdisFMJx5vZ6Jk2s6e6qDfPg4RKEar9zgsrtxzuQAIcP1FePs2+GDTUCd8DgFa uxGyKKRN+htmj85o1bSTEDL1Ps3NIOMFJVDxpYdH8mKgd3yQO+UHTMttTWe6Vw7EzWjmc8pan0S O5MbM2wO4i80UDF7m2cFYSiNdkHGirsoH/pr9GGnZDG1Q5SCMKQZTcgbwVdyXbkzdOfXjgKhg+a bGsVPbZNjxOyGcpW1yvqoX++xe5HkgatQ4YEm52V0Y49uOEDmSaR4aMeXTAYf2KGDyMUjF30sHF RLYaa+hR6zp8ei7hRpMyngjsnTrzb2206Co8fc6zcQfWQWZhx8NCRrQbCn1sDbS6///qNS1UDiD hpReGYHmzJw7rL4UfmI9a084/IjNSqSeQmZfiAMYm++WWwt30NWJnw= X-Received: by 2002:a05:600c:b93:b0:499:59da:12b9 with SMTP id 5b1f17b1804b1-499825cefdcmr4797315e9.0.1786576417330; Wed, 12 Aug 2026 16:13:37 -0700 (PDT) Received: from Neo.taile6b6ba.ts.net (ip-109-193-028-127.um39.pools.vodafone-ip.de. [109.193.28.127]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49981b631c1sm44532245e9.14.2026.08.12.16.13.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Aug 2026 16:13:36 -0700 (PDT) From: Marek Czernohous To: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org, Danilo Krummrich , Lyude Paul , David Airlie , Simona Vetter , Ben Skeggs Subject: [PATCH v3 4/4] drm/nouveau: subscribe to channel-kill events on NV50 and newer Date: Thu, 13 Aug 2026 01:13:30 +0200 Message-ID: <20260812231330.705425-5-mczernohous@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260812231330.705425-1-mczernohous@gmail.com> References: <20260812231330.705425-1-mczernohous@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Marek Czernohous nouveau_channel_init() only subscribes to the channel-killed event for FERMI_CHANNEL_GPFIFO and newer. On NV50/Tesla the subscription therefore never happens, and nvkm_chan_error()'s NVKM_CHAN_EVENT_ERRORED is delivered into an empty notifier list. Today that is harmless, because nothing kills a channel on Tesla: the only nvkm_chan_error() callers are the Fermi and newer recovery paths. So this patch changes no observable behaviour on its own, and that is deliberate: it removes a latent trap before anything can fall into it. I am carrying a Tesla recovery path that does add such a caller and will send it separately once it is ready. Without a subscriber in place the consequences there are severe: nouveau_channel_killed() never runs, so nouveau_fence_context_kill() never runs either, and the pending fences of the killed channel are never signalled. Everything waiting on them waits forever: drm_atomic_helper_wait_for_fences() in the display commit tail waits uninterruptibly and without a timeout, and the TTM delayed delete workers wait in TASK_UNINTERRUPTIBLE. The user sees a frozen desktop on a machine that is otherwise alive, and nothing in the kernel ends that state: both waits pass MAX_SCHEDULE_TIMEOUT, so the fences cannot time out. They are signalled only when the fence context is torn down, that is when the DRM client owning the channel closes its fd and nouveau_fence_context_del() runs. Killing the client, or rebooting, clears it; waiting does not. That is also a dma-fence contract violation: a fence must always be signalled, with an error if necessary. Lower the class gate to NV50_CHANNEL_GPFIFO. The nvkm side is already class neutral: the KILLED case hangs the notifier on runl->chid->event, which every fifo owns since the runlist rework, and nvkm_uchan_uevent() does not discriminate by class. Pre-NV50 chips keep the old behaviour, so NV04 to NV40 are unaffected. Assisted-by: Claude:claude-opus-5 Signed-off-by: Marek Czernohous --- drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c b/drivers/gpu/drm/nouve= au/nouveau_chan.c index 07b0bd1bc519..5c2f4b9342b7 100644 --- a/drivers/gpu/drm/nouveau/nouveau_chan.c +++ b/drivers/gpu/drm/nouveau/nouveau_chan.c @@ -485,7 +485,7 @@ nouveau_channel_init(struct nouveau_channel *chan, u32 = vram, u32 gart) * lock and the pending list, so an event arriving in between would * find a non-NULL but unusable context and walk a NULL list head. */ - if (chan->user.oclass >=3D FERMI_CHANNEL_GPFIFO) { + if (chan->user.oclass >=3D NV50_CHANNEL_GPFIFO) { DEFINE_RAW_FLEX(struct nvif_event_v0, args, data, sizeof(struct nvif_chan_event_v0)); struct nvif_chan_event_v0 *host =3D --=20 2.54.0