On Tue Feb 17, 2026 at 3:28 PM CET, Philipp Stanner wrote: > OK, maybe I'm lost, but what delayed_work? > > The jobqueue's delayed work item gets either created on JQ::new() or in > jq.submit_job(). Why would anyone – that is: any driver – implement a > delayed work in its timeout callback? > > That doesn't make sense. > > JQ notifies the driver from its delayed_work through > timeout_callback(), and in that callback the driver closes the > associated firmware ring. > > And it drops the JQ. So it is gone. A new JQ will get a new timeout > work item. > > That's basically all the driver must ever do. Maybe some logging and > stuff. > > With firmware scheduling it should really be that simple. > > And signalling / notifying userspace gets done by jobqueue. > > Right?
Well, the timeout path is part of the fence signaling critical section until all fences have been signaled. But, if I, for instance, just kick off another work from the timeout handler and subsequently signal all fences by dropping the JQ, this other work must not play after DMA fence signaling rules anymore and is free to do whatever (maybe even take a device coredump without needing GFP_NOWAIT). Xe does this with xe_devcoredump_deferred_snap_work for instance. >> You also potentially want device core dumps. Those usually use GFP_NOWAIT so >> that they can't cycle back and wait for some fence. The down side is that >> they can trivially fail under even light memory pressure. > > Simply logging into dmesg should do the trick, shouldn't it? You can't "log" a device coredump into dmesg. :)
