From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 95264C98321 for ; Fri, 25 Sep 2026 17:32:56 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CBA2510E094; Fri, 25 Sep 2026 17:32:55 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="BtGM5+BJ"; dkim-atps=neutral Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4447210E094 for ; Fri, 25 Sep 2026 17:32:55 +0000 (UTC) Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id D65A840605; Fri, 25 Sep 2026 17:32:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 007401F000FF; Fri, 25 Sep 2026 17:32:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790357574; bh=XX5xuckpzIuBGSkpTDAZLOD0oioLLWvieHwioo1oDWQ=; h=Date:Subject:Cc:To:From:References:In-Reply-To; b=BtGM5+BJ88YkzDX70KvcCtZ2YFT1jDLJxL0cCIZBFqM6T515dC9yMTR/mn6rHr2Rp CN5q8Ybuc3huauaPrW9Hs8OAw6OMMsk/ZEs2KI2GLDIcgIIxmC5KeYJrsQ99VQ9/Ce pia5WKjlHdcTpVgsbyNJf9ZPZ+kv/Wh/EqJT802q2cn+V+fx2od75rPNsNskKj9gfP cBqhtuRa32xw16owzpJtMC+Zkju6G4YsY9GnJKOcGHNTWb7Hofodt3Q0j/N+E31l2S bkThUwVyBg4D5yfdmlBkWi10cFSq9b9WvqiT1SrhAj5KLZgdPzmVOL0XqMqLuZMh1S byDZUjeyY6eIw== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 25 Sep 2026 19:32:49 +0200 Message-Id: Subject: Re: [PATCH] rust: DmaFence: Add better warning through Device reference Cc: , "Gary Guo" , "Alice Ryhl" , "Sumit Semwal" , =?utf-8?q?Christian_K=C3=B6nig?= , "Miguel Ojeda" , "Boqun Feng" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Benno Lossin" , "Andreas Hindborg" , "Trevor Gross" , "Daniel Almeida" , "Tamir Duberstein" , "Alexandre Courbot" , =?utf-8?q?Onur_=C3=96zkan?= , , , , To: "Philipp Stanner" From: "Danilo Krummrich" References: <20260925081958.3048112-2-phasta@kernel.org> In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri Sep 25, 2026 at 7:21 PM CEST, Philipp Stanner wrote: > On Fri, 2026-09-25 at 17:50 +0200, Danilo Krummrich wrote: >> On Fri Sep 25, 2026 at 3:08 PM CEST, Philipp Stanner wrote: >> > The driver can avoid dropping half-forgotten stuff by calling >> > jobqueue.complete_all_jobs(ECANCELED) immediately before dropping, >> > which allows us for having the warning without false-positives. >>=20 >> This would just move it up a layer from inventing a new type around Driv= erFence >> to invent a new type around Jobqueue which does that instead. >>=20 >> But the Jobqueue won't have any procedural teardown, it has to teardown = stuff in >> drop() anyway, which includes dropping jobs already. >>=20 >> What I'm saying is that there's not much value in DriverFence::drop() ha= ving >> this warning in the first place, which then either the driver or the job= queue >> has to work around on teardown. > > I guess we agree that it would be a horrible bug if there's still a > command buffer running on the GPU that can access memory which might > have been freed once the associated fence signaled. Sure, but that's unrelated. > So I suppose what you are saying is more: there is not much value in > the case of *JobQueue*, basically because all the jobs live inside of > it anyways. No, I'm saying there is not much value in general. Whatever thing owns the DriverFence has to represent the "device access" of some resource, which already naturally establishes the relationship. IOW, whatever thing owns a DriverFence is also the thing that stops the har= dware in its own drop() implementation; anything else would be rather questionabl= e. > So I suppose we agree that a warning is fine. It won't fire in JQ > anyways, but might benefit others. What scenario are you thinking of?