[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

[bugzilla-daemon at bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=207383

--- Comment #92 from Nicholas Kazlauskas (nicholas.kazlauskas at amd.com) ---
This sounds very similar to a bug I fixed a year ago but that issue was with
freeing the dc_state.

https://bugzilla.kernel.org/show_bug.cgi?id=204181

1. Client requests non-blocking Commit #1, has a new dc_state #1,
state is swapped, commit tail is deferred to work queue

2. Client requests non-blocking Commit #2, has a new dc_state #2,
state is swapped, commit tail is deferred to work queue

3. Commit #2 work starts before Commit #1, commit tail finishes,
atomic state is cleared, dc_state #1 is freed

4. Commit #1 work starts after Commit #2, uses dc_state #1, NULL pointer deref.

This issue was fixed, but it occurred under similar conditions - heavy system
load and frequent pageflipping.

However, in the case of dm_state things can't be solved in the same manner.
Commit #2 can't free Commit #1's commit - only the commit tail for Commit #1
can free it along with the IOCTL caller.

I don't know if this is going down any of the deadlock paths in DRM core
because that might trigger strange behavior as well with clearing/putting the
dm_state.

If someone who can reproduce this issue can produce a dmesg log with the DRM
IOCTLs logged (I think drm.debug=0x54 should work) then I should be able to
examine the IOCTL sequence in more detail.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.