From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 802933B7B6E; Mon, 28 Sep 2026 10:44:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790592244; cv=none; b=mPz7zvOupddTgUkGIecExg0JPGZXrRCAoG23V4+QNR6oFs4LP1efA7i/vdmyCKDeMHBy33HodzG46nkUHK2pWRrjqykjQY29wjdkSoZEum9Rx0mgI7ghwbJwhEKFjZbdHBJt2L7kw5IcgjqSkwFoKti3ogngYv7tcK+zGfNph6c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790592244; c=relaxed/simple; bh=5SfTuxAiSv4mvZ89TZUYw5wDEzGgBJFCQM8+4xeEwfE=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:To:From: References:In-Reply-To; b=pPsjSr1r5CdCpwrQ8NS6Hmp0nE9LpBgb8+iLpcyL9P177aw8xJflNsEM0F66SUnMaZ6AFUSpy10r7oRe8fICmOzY5gGXSjvTFjLGb4P7IABiB/DVKdRTW6oo6N0rdrjIw4KAGPCavRkCsm5fKpEOF4Qkn+yh4ah12hXCCVsB/sU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Z4jfKm8t; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z4jfKm8t" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 281B61F000FF; Mon, 28 Sep 2026 10:43:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790592243; bh=Mp3XtGy21aQRxosj8wN/TOa0Q0Kwk8FEiqjAOGlRKRA=; h=Date:Subject:Cc:To:From:References:In-Reply-To; b=Z4jfKm8tURgzkzDL8XMRwfRfzIx6XQt9YZ3Cj5pnOFDdx9l+/VWZPCzVfKGoLILhV kwyWZ7ZjgtWu4UV4VJIsbSu5w+WcMUw2oGCOS5rHSQYm1RRokk84vXQ6YRJj0LkOhc 5ognTu+rOZRN5YMdnW1SmVs0tSsnzi25zPkOqsFBkuJ0AJJajd0NMUGvwtmmPPA5Ty 95oF6vcOBJD77eaYExtR5IDk6V2U8SPws8oHSofzVjF2WHhhiTtrNN1WJ2utgF+DR4 o/ElFe3+3iM/ZLt8mjy8KOAggC0m34zuQXjbHixJ7Gw6RhTlo83clvqvB4/mubwyvA z6FQo7senxhKw== 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 Date: Mon, 28 Sep 2026 12:43:57 +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> <37a2858a4687e4d9bbe0aba4c1861b96875c4ed7.camel@mailbox.org> In-Reply-To: On Mon Sep 28, 2026 at 10:32 AM CEST, Philipp Stanner wrote: > On Mon, 2026-09-28 at 10:11 +0200, Danilo Krummrich wrote: >> On Mon Sep 28, 2026 at 9:52 AM CEST, Philipp Stanner wrote: >> > > > So I suppose we agree that a warning is fine. It won't fire in JQ >> > > > anyways, but might benefit others. >> > >=20 >> > > What scenario are you thinking of? >> >=20 >> > Drivers doing "rather questionable" things, like we've seen a great >> > many times already ;) >> >=20 >> > Note that the dma_fence backend fires a WARN_ON if a fence is freed >> > unsignaled, too, for the same reason. >> >=20 >> > Life finds a way. >>=20 >> I'd rather you engage with the arguments I made above and give a concret= e >> example of how it "might benefit others", instead of resorting to know-i= t-all >> platitudes. > > Stating that I cannot know nor conceive all possible patterns and > misbehaviors is quite literally me acknowledging that I do *not* "know > it all". I mean, you expressed a concern about a fence being signaled before the har= dware has been torn down accordingly. I provided arguments why I don't see that t= he concern holds and then you mentioned that the warning "might benefit others= ". To me this sounded as if you had concrete scenarios in mind, which doesn't = seem to be the case. If that's correct, and given that there was no reply to my arguments, it seems we can just remove it. Maybe to further explain my reasoning: The concern was that it could happen that the DriverFence is dropped while = the hardware still utilizes the memory "protected" by the fence. As mentioned, = to me this is not a concern because of the programming model we have in Rust. Tak= e this analogous DMA memory example: struct Channel<'a> { shared: dma::Coherent<'a, Data>, } =09 impl Drop for Channel<'_> { fn drop(&mut self) { self.stop_hardware(); shared.free(); } } We could use the exact same argument to require people to explicitly call f= ree() on a dma::Coherent allocation as the underlying hardware (represented by th= e channel) could still use the dma::Coherent allocation if we "drop it accidentally". But as you can see, the ownership is already properly expressed by Rust, th= e Channel owns the dma::Coherent allocation, so the memory can just be freed = in Coherent::drop(). The same applies to DriverFence, the thing that takes ownership is the thin= g that operates the hardware. > With this patch I was just trying to accommodate your post-merge > request for replacing pr_ with dev_err() or WARN_ON. If you think > neither is actually necessary, that's also fine by me. I did arrive at the conclusion to discuss whether we can't just get rid of = the warning entirely in my first reply [1], which you refer to, already. [1] https://lore.kernel.org/all/DL9AEUZ4VGV5.2RT33JE0MHYME@kernel.org/