Re: [PATCH] rust: DmaFence: Add better warning through Device reference

[Danilo Krummrich]

On Mon Sep 28, 2026 at 9:52 AM CEST, Philipp Stanner wrote:
> On Fri, 2026-09-25 at 19:32 +0200, Danilo Krummrich wrote:
>> On Fri Sep 25, 2026 at 7:21 PM CEST, Philipp Stanner wrote:
>> > 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 hardware
>> in its own drop() implementation; anything else would be rather questionable.
>> 
>> > 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?
>
> Drivers doing "rather questionable" things, like we've seen a great
> many times already ;)
>
> Note that the dma_fence backend fires a WARN_ON if a fence is freed
> unsignaled, too, for the same reason.
>
> Life finds a way.

I'd rather you engage with the arguments I made above and give a concrete
example of how it "might benefit others", instead of resorting to know-it-all
platitudes.

The comparison with C does not address my point about ownership: C relies on
explicit cleanup, whereas the Rust design I described ties cleanup to ownership
through RAII.

Again, please address the arguments I've already made.