On Tue, Jan 21, 2025 at 02:14:56AM +0100, Xaver Hugl wrote: > > +It is the responsibility of the consumer to make sure that the device or > > +its resources are not in use by any process before attempting recovery. > I'm not convinced this is actually doable in practice, outside of > killing all apps that aren't the one trying to recover the GPU. > Is this just about not crashing those processes if they don't handle > GPU hotunplugs well, about leaks, or something else? Correct, all of it. And since the compositor is in charge of device resources, this way it atleast has the opportunity to recover the device and recreate context without all the userspace violence. I'm not entirely aware of its feasibility though, perhaps something for the consumers to experiment. > > +With IOCTLs blocked and device already 'wedged', all device memory should > > +be unmapped and file descriptors should be closed to prevent leaks. > Afaiu from a userspace POV, a rebind is just like a GPU hotunplug + > hotplug with matching "remove" and "add" udev events. As long as the > application cleans up resources related to the device when it receives > the event, there should be no leaks with a normal hotunplug... Is this > different enough that we can't have the same expectations? The thing about "remove" event is that it is generated *after* we opt for an unbind, and at that point it might be already too late if userspace doesn't get enough time to clean things up while the device is removed with a live client resulting in unknown consequences. The idea here is to clean things up *before* we opt for an unbind leaving no room for side effects. Raag
