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

["Danilo Krummrich" <dakr@kernel.org>]

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.
>> 
>> This would just move it up a layer from inventing a new type around DriverFence
>> to invent a new type around Jobqueue which does that instead.
>> 
>> But the Jobqueue won't have any procedural teardown, it has to teardown stuff in
>> drop() anyway, which includes dropping jobs already.
>> 
>> What I'm saying is that there's not much value in DriverFence::drop() having
>> this warning in the first place, which then either the driver or the jobqueue
>> 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 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?