From: Pavel Machek <pavel@ucw.cz>
To: Chris Wilson <chris@chris-wilson.co.uk>,
kernel list <linux-kernel@vger.kernel.org>
Cc: intel-gfx@lists.freedesktop.org,
Mika Kuoppala <mika.kuoppala@linux.intel.com>,
stable@vger.kernel.org
Subject: 4.19-stable: Re: [PATCH 2/3] drm/i915: Break up error capture compression loops with cond_resched()
Date: Mon, 9 Nov 2020 11:24:37 +0100 [thread overview]
Message-ID: <20201109102437.GA15835@amd> (raw)
In-Reply-To: <20200916090059.3189-2-chris@chris-wilson.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]
Hi!
> 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.
>
> 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>
This was queued for 4.19-stable, but is very likely wrong.
> @@ -397,6 +399,7 @@ static int compress_page(struct i915_vma_compress *c,
> if (!(wc && 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... and if userland access
blocked, we would be able to reschedule, anyway.
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
parent reply other threads:[~2020-11-09 10:24 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20200916090059.3189-2-chris@chris-wilson.co.uk>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201109102437.GA15835@amd \
--to=pavel@ucw.cz \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.kuoppala@linux.intel.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).