On Fri, 2026-09-25 at 14:30 +0200, Danilo Krummrich wrote: > On Fri Sep 25, 2026 at 12:26 PM CEST, Gary Guo wrote: > > On Fri Sep 25, 2026 at 9:19 AM BST, Philipp Stanner wrote: > > > Replace the warning print with a dev_warn!(). To do so, have the > > > FenceContext carry a reference to a Device, protected by the already > > > present lifetime. > > > > Add a lifetime just to do this a print doesn't sound ideal. You could use > > `ARef<Device>` instead? > > Yes, that's what I recommend in general.
Weren't you super opposed to refcounting wherever it's avoidable? […] > That said, we can also use WARN_ON() instead, which avoids the device > dependency > to begin with and still provides enough information to find the "offender". WARN_ON() is fine by me. > > But as I mentioned previously, I don't consider this that bad of a condition > in > the first place. Signaling with ECANCELED on drop() seems perfectly > reasonable: > > When a driver does a teardown of the channel (or more generically the > execution > context) it will follow the RAII pattern, so it will be very natural to just > drop the Jobqueue, which will drop all jobs and hence all DriverFence objects. > > IOW, driver will likely invent a new type that does the same thing on drop, > just > without the warning. :) 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. P.
