Hi! > commit 7d5553147613b50149238ac1385c60e5c7cacb34 upstream. > > As the error capture will compress user buffers as directed to by the > user, it can take an arbitrary amount of time and space. Break up the > compression loops with a call to cond_resched(), that will allow other > processes to schedule (avoiding the soft lockups) and also serve as a > warning should we try to make this loop atomic in the future. This was queued for 4.19-stable, but is very likely wrong. > Testcase: igt/gem_exec_capture/many-* > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala > Cc: stable@vger.kernel.org > Reviewed-by: Mika Kuoppala > Link: https://patchwork.freedesktop.org/patch/msgid/20200916090059.3189-2-chris@chris-wilson.co.uk > (cherry picked from commit 293f43c80c0027ff9299036c24218ac705ce584e) > Signed-off-by: Rodrigo Vivi > Signed-off-by: Greg Kroah-Hartman > @@ -347,6 +349,7 @@ static int compress_page(struct compress > if (!i915_memcpy_from_wc(ptr, src, PAGE_SIZE)) > memcpy(ptr, src, PAGE_SIZE); > dst->pages[dst->page_count++] = ptr; > + cond_resched(); > > return 0; > } 4.19 compress_page begins with static int compress_page(struct compress *c, ... page = __get_free_page(GFP_ATOMIC | __GFP_NOWARN); and likely may not sleep. That changed with commit a42f45a2a85998453078, but that one is not present in 4.19.. I believe we don't need this in stable: dumping of error file will not take so long to trigger softlockup detectors... Best regards, Pavel > -- http://www.livejournal.com/~pavelmachek