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 chris@chris-wilson.co.uk Cc: Mika Kuoppala mika.kuoppala@linux.intel.com Cc: stable@vger.kernel.org Reviewed-by: Mika Kuoppala mika.kuoppala@linux.intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20200916090059.3189-2-chris@ch... (cherry picked from commit 293f43c80c0027ff9299036c24218ac705ce584e) Signed-off-by: Rodrigo Vivi rodrigo.vivi@intel.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
@@ -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