https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #92 from Nicholas Kazlauskas (nicholas.kazlauskas@xxxxxxx) --- 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
