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.
