From: Daniel Vetter <daniel@ffwll.ch>
To: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: intel-gfx@lists.freedesktop.org, Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH] drm/i915: Fix possible overflow when recording semaphore states.
Date: Mon, 21 Jul 2014 11:20:47 +0200 [thread overview]
Message-ID: <20140721092047.GV15237@phenom.ffwll.local> (raw)
In-Reply-To: <20140719020039.GA4045@intel.com>
On Fri, Jul 18, 2014 at 07:00:40PM -0700, Ben Widawsky wrote:
> On Fri, Jul 18, 2014 at 02:19:40AM -0700, Rodrigo Vivi wrote:
> > semaphore _sync_seqno, _seqno and _mbox are smaller than number of rings.
> > This optimization is to remove the ring itself from the list and the logic to do that
> > is at intel_ring_sync_index as below:
> >
> > /*
> > * rcs -> 0 = vcs, 1 = bcs, 2 = vecs, 3 = vcs2;
> > * vcs -> 0 = bcs, 1 = vecs, 2 = vcs2, 3 = rcs;
> > * bcs -> 0 = vecs, 1 = vcs2. 2 = rcs, 3 = vcs;
> > * vecs -> 0 = vcs2, 1 = rcs, 2 = vcs, 3 = bcs;
> > * vcs2 -> 0 = rcs, 1 = vcs, 2 = bcs, 3 = vecs;
> > */
> >
> > v2: Skip when from == to (Damien).
> > v3: avoid computing idx when from == to (Damien).
> > use ring == to instead of ring->id == to->id (Damien).
> > use continue instead of return (Rodrigo).
> > v4: avoid all unecessary computation (Damien).
> > reduce idx to loop scope (Damien).
> >
> > Cc: Damien Lespiau <damien.lespiau@intel.com>
> > Cc: Ben Widawsky <benjamin.widawsky@intel.com>
> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > ---
> > drivers/gpu/drm/i915/i915_gpu_error.c | 21 ++++++++++++++-------
> > 1 file changed, 14 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c
> > index 9faebbc..0b3f694 100644
> > --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> > @@ -764,7 +764,7 @@ static void gen8_record_semaphore_state(struct drm_i915_private *dev_priv,
> > struct intel_engine_cs *ring,
> > struct drm_i915_error_ring *ering)
> > {
> > - struct intel_engine_cs *useless;
> > + struct intel_engine_cs *to;
> > int i;
> >
> > if (!i915_semaphore_is_enabled(dev_priv->dev))
> > @@ -776,13 +776,20 @@ static void gen8_record_semaphore_state(struct drm_i915_private *dev_priv,
> > dev_priv->semaphore_obj,
> > &dev_priv->gtt.base);
> >
> > - for_each_ring(useless, dev_priv, i) {
> > - u16 signal_offset =
> > - (GEN8_SIGNAL_OFFSET(ring, i) & PAGE_MASK) / 4;
> > - u32 *tmp = error->semaphore_obj->pages[0];
> > + for_each_ring(to, dev_priv, i) {
> > + int idx;
> > + u16 signal_offset;
> > + u32 *tmp;
> >
> > - ering->semaphore_mboxes[i] = tmp[signal_offset];
> > - ering->semaphore_seqno[i] = ring->semaphore.sync_seqno[i];
> > + if (ring == to)
> > + continue;
> > +
> > + signal_offset = (GEN8_SIGNAL_OFFSET(ring, i) & PAGE_MASK) / 4;
> > + tmp = error->semaphore_obj->pages[0];
> > + idx = intel_ring_sync_index(ring, to);
> > +
> > + ering->semaphore_mboxes[idx] = tmp[signal_offset];
> > + ering->semaphore_seqno[idx] = ring->semaphore.sync_seqno[idx];
> > }
> > }
> >
>
> Just elaborate on previous email from your v1, now that you've fixed the
> error state printing, I would have rather not skip the check and instead
> expand the array. This would help us find stray, or unexpected writes
> with either future bugs, or buggy hardware.
>
> I'm not asking for a v5 (but I did ask you to make a note of what we
> miss in the commit message when I responded to v1... but that's okay
> too). I am simply explaining the earlier mail in case it was unclear. If
> a v5 *does* need to happen anyway, that is still my preference, but I
> don't care too much.
>
> (Also, I think v2 in your commit message was (Ben), not (Damien) but
> perhaps I missed a conversation somewhere)
We could do this as a follow-up, merged the current version to dinq.
>
> Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
>
> P.S.
> I'd be in favor of adding BUG_ON(idx >= I915_NUM_RINGS) before return in
> intel_ring_sync_index().
BUG_ON considered harmful, please use WARN_ON instead. But not sure how
much this is worth it here really.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
prev parent reply other threads:[~2014-07-21 9:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-17 12:35 [PATCH] drm/i915: Fix possible overflow when recording semaphore states Rodrigo Vivi
2014-07-17 21:31 ` Ben Widawsky
2014-07-18 10:29 ` Damien Lespiau
2014-07-18 8:39 ` Rodrigo Vivi
2014-07-18 15:47 ` Damien Lespiau
2014-07-18 9:05 ` Rodrigo Vivi
2014-07-18 16:12 ` Damien Lespiau
2014-07-18 9:19 ` Rodrigo Vivi
2014-07-19 2:00 ` Ben Widawsky
2014-07-21 9:20 ` Daniel Vetter [this message]
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=20140721092047.GV15237@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=benjamin.widawsky@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=rodrigo.vivi@intel.com \
/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