Linux kernel (drivers/gpu/drm/xe): A tenant that suspends an exec queue and then closes it while the GuC

Impact

A tenant that suspends an exec queue and then closes it while the GuC scheduling-disable is still in flight desynchronises the driver's view of GuC state - the late response deregisters a queue that was never marked for destruction. That corrupts submission state for the whole GT (affecting co-tenants sharing the engine) and leaves the queue object referenced after teardown.

Who can reach it

Tenant container holding /dev/dri/renderD* on Intel xe: request suspend on an exec queue, then kill/close it before the GuC round-trip completes. Timing is easy to win - the trace in the fix shows the whole window is under a millisecond and it reproduces in ordinary test runs.

What to do

Update to a kernel carrying the fix (stable commits below; no fixed_in published). No practical interim control - exec queue suspend and close are core submission ioctls.

References