From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (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 55E3D3E5A32 for ; Thu, 6 Aug 2026 10:00:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786010402; cv=none; b=BJ8s8mL0eZ9BwiZjtpKWcKHx1+aeRs41vlaautkYPixdVDToRCaxvIX/tPDbFH8qPwVROjiLgwyQ0ik8T4CZh5jzTgYZNRsxBLNMOXAdWnQGTUziwCb/rA/G48CPNj8JwD4U4LMXVumcjFJrBuzqxhRd99kQaG1vDzxOut63Fhw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786010402; c=relaxed/simple; bh=tlTgAAZIu1G/G4ReqmF6Dc4yI/+5/eXrfwCBMcLT+KQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Y8zd+qeqi/CyzX2934U/tsbnvsotFfo2IlTzeoukIebBv+rvzOhx6WrZYvOQLg5AczRGFR6oOLcFgZiVanNHQ40kUdhMeftL77pAmKKvfKj2N/anNiQJ1FIYaIspiENSVEtAU2BtsXD6eG//tt7nVNbTzA4SLO19IKTpENZHppc= 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=DYRmHOEt; arc=none smtp.client-ip=209.85.128.48 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="DYRmHOEt" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-496c5280812so594595e9.0 for ; Thu, 06 Aug 2026 03:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786010399; x=1786615199; 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=8102EMdRsA752wQbhXTdKaIRmXwR/nDaRkxmP1E6VH4=; b=DYRmHOEtYxF0yKJLXxTJmDxtJJDe6o6uZexhS+bLo5KLwQCe1GUVkOeymkUa+uWr9l /bTRggQP6b1qexFN9cRynHg1Fa2Rum+8BVihNSMWLPmGZlaWvBwVFQNYAdE0ipmjtoLo EWt99qEdSWnl1pcJLfqyAeqeLcT+NTpV317KO3py2KjesvpjYly2mruzFxw9rhemwR3C ziQBLn6LTHcv/XfAIFsHAEuJ+U4UZpxLi1HImuXcS9xEh/ug3kEg2gutKujenIkNwPAX 3PtQ8Sxsh56JU0HoeGUhzrkHlYv4t/fJnkTKffstymJ5AXidMXfGSIRL6I9mJSLiVGqZ G3Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786010399; x=1786615199; 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=8102EMdRsA752wQbhXTdKaIRmXwR/nDaRkxmP1E6VH4=; b=gNQ82tQLaO/JNpFEczZ3pl3A2Xvw3Y/4+l8N4OzlUiJFwEZIFVbCXKN3xPggmB5Px5 WaVJc+OMm4Vf+3URgQZacvIAX+8arJDzkhX+y92rOoKp7L6VxRnuTmGCiobo3bqoTPh0 RZudlqwqB6PxCKoMVE7bib4B2Y9jw+XMCY7nPLrg8z/17nAX3RooLQc01sVUB/attZQG me0vHmUtxq4kCnKcn4RE/2VdQm997omOCcXlgPYbl3GrtRK45Y4p+C5F/YobtZGP2GJ/ KAndcPLuNBqvHs37zDgC6Clh8U9AZozd5AFGdm3oTGMWmOm4tUyP9BnASIrIfykKym7g raeQ== X-Forwarded-Encrypted: i=1; AHgh+RoQHCQtpG/+KGwWmwRBZJ9jMRYOF3JwLAc6qQQL46QbC74NDcERrCrgwkfhkxg7TgrNMKhEFks720Mw06E=@vger.kernel.org X-Gm-Message-State: AOJu0YzJgMje3VodcrKxTcC4Hxk4cF3k+mt/YqulZYRsjkg4BWPA08Wm xdwkSedqmjkNEXhaUKC2Fwtc/BJivodFKP84VlrMqDubkmYAflgqfljU X-Gm-Gg: AR+sD113QFKMrpTN61qlBSGwZeKSDKSBkeDcPSQdG2jX0IrnvuERcAgTkvDagwOt3Zi Yh3eKi1njb+OXncyHWvjK7RPUVIhtVnC/8KKGfsADopnNS1OBr1eT+o4eWW0lpUnfs6dY6VZUsW a9r51aHx4a5231elvofCxXBxrSyaKqrAamoMSNdc5B1kjXJeItP63ZGlVfF3ZCjCmNEMMt+GYhF gn6v9EbQQQ2ZhT/5bcOEK4COF+SDXxlevJpChWmQsUVnYQ2f30MFL735PZVhK0MTJmzJxz4jL7L YhwZENPRWO0R2V+RP4JqM8HakUfDxYpRrYS3s16F0pcWtfUV8LOqgylsFFALAUympUTvvGLlMzg OnYFAsGv1HISv8NO9SExiFKEnpJhfejn95JSN/5BXGhB6EeIAXvuNqaVMp4NAJgsM60slIN7260 0Yx2z3vn4mXZrVdg7LpET+bFLsZJWwmPcmUOabzlUONqggEErv0SqWR8HkKu0Uu4Q5rIjWLj0vw 7ZOMQWX0XViZ4vkJMzAgHoNGdA2e0QQXd4AH6YkzAabItOLdn5cL7Kb8lL6MU3zVQ== X-Received: by 2002:a05:600c:1393:b0:495:650b:4c61 with SMTP id 5b1f17b1804b1-4994e7d0166mr98743685e9.3.1786010399195; Thu, 06 Aug 2026 02:59:59 -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-49954206d9dsm56510905e9.2.2026.08.06.02.59.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 02:59:58 -0700 (PDT) From: Marek Czernohous To: nouveau@lists.freedesktop.org Cc: Lyude Paul , Danilo Krummrich , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/3] drm/nouveau: nv04 FIFO cleanup + recovery for Tesla Date: Thu, 6 Aug 2026 11:59:57 +0200 Message-ID: <20260806095957.1908908-1-mczernohous@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260806085228.1848994-1-mczernohous@gmail.com> References: <20260806085228.1848994-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: 8bit Both findings are correct, thank you. I checked them against mainline rather than against my downstream tree: 1) nouveau_channel_del() frees the fence context first and only drops the kill subscription later, among the nvif object teardown calls. The subscribed handler reaches nouveau_fence_context_kill(chan->fence), so a kill delivered in that window takes fctx->lock and walks fctx->pending on a context that context_del() has already freed. 2) nouveau_channel_init() arms the subscription right after mapping userd and creates the fence context at the end of the same function. The backends publish the pointer before the context is usable: fctx = chan->fence = kzalloc_obj(*fctx); if (!fctx) return -ENOMEM; nouveau_fence_context_new(chan, &fctx->base); and it is nouveau_fence_context_new() that runs spin_lock_init(&fctx->lock) and INIT_LIST_HEAD(&fctx->pending). The NULL check in nouveau_channel_kill() does not cover that window: chan->fence is non-NULL and unusable, so the handler locks something that was never initialised and walks a list head whose next pointer is still the NULL left by kzalloc(). Both are unreachable below Fermi today, which is exactly why they belong in this series: 2/3 lowers the gate to NV50 and 3/3 adds the caller that kills Tesla channels. This series is what makes them reachable, so shipping it without them would trade a recoverable fault for a use-after-free. I should have carried the first one from the start. It has been running on the reference machine since 2026-07-25, and my v2 cover letter described that same ordering and then dismissed it as "most of that window is harmless". That judgement was wrong. v3 will put both in front of the subscription change, as 1/5 and 2/5, with the remaining three unchanged apart from the rebase.