Description
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: force complete the MES ring fences on reset The MES scheduler ring has no drm scheduler (no_scheduler = true), so it is skipped by the force-completion loop in amdgpu_device_pre_asic_reset(). It uses a polling fence whose hw value lives in wb (GTT) memory and survives a MODE1 reset, while fence_drv.sync_seq keeps advancing for every packet. When the reset is triggered because MES itself stopped responding, the timed-out packets advance sync_seq past the last hw fence value MES wrote. After resume the first MES submission polls forever on a seq that is never written back, failing the resume and wedging the box on a second reset: amdgpu: MES ring buffer is full. amdgpu: *ERROR* ring gfx_0.0.0 test failed (-110) amdgpu: resume of IP block <gfx_v11_0> failed -110 amdgpu: GPU reset end with ret = -110 Force complete the MES scheduler ring fences together with the scheduler rings so their hw fence is realigned to sync_seq. v2: cover all XCCs (one scheduler ring each), not just mes.ring[0].
Affected products
Version statuses are supplied by the assigning organization. Consult the original record for detailed ranges and platform conditions.
Linux Linux
Default version status: unaffected
34e087e8920e635c62e2ed6a758b0cd27f836d13 to < c48d5a4d2863e56a6692ecb6cd6c32404f40cd0faffected34e087e8920e635c62e2ed6a758b0cd27f836d13 to < 7d722821e2f626c4e34c8510f0ce1d6f10c77a3baffected34e087e8920e635c62e2ed6a758b0cd27f836d13 to < ebe7542553d008e2285e0fbba0c63f0295a7e694affected34e087e8920e635c62e2ed6a758b0cd27f836d13 to < 48dc279c3010ac8f91b1845b2abb3a1e9943a0f5affected
Linux Linux
Default version status: affected
6.12affected0 to < 6.12unaffected6.12.114 to ≤ 6.12.*unaffected6.18.57 to ≤ 6.18.*unaffected7.2.5 to ≤ 7.2.*unaffected7.3 to ≤ *unaffected