All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Mahoney <jeffm@suse.com>
To: Ben Skeggs <bskeggs@redhat.com>,
	dri-devel@lists.freedesktop.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: [PATCH] nouveau: Fix race with fence signaling
Date: Tue, 22 Oct 2013 15:15:56 -0400	[thread overview]
Message-ID: <5266CEEC.2010606@suse.com> (raw)

There exists a tight race between the call to nouveau_fence_done from
nouveau_fence_wait and the call to nouveau_fence_wait_uevent.

nouveau_fence_done checks to see if fence->channel is NULL before calling
nouveau_fence_wait_uevent, but it's not good enough since the dereference
in nouveau_fence_wait_uevent is done outside the lock. Another thread
may have signaled the fence in that tight window and then we Oops
while dereferencing fence->channel->drm at the beginning of
nouveau_fence_wait_uevent.

The good news is that nouveau_fence_wait_uevent only uses fence->channel
directly to grab the chan->drm pointer. If we pass that in directly as
a known good pointer, we can avoid the race. Passing the nouveau_fence_done
check in the caller ensures that the chan pointer is valid.

Original bug report at: https://bugzilla.novell.com/show_bug.cgi?id=844177

Cc: <stable@vger.kernel.org> # 3.9+
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
---
 drivers/gpu/drm/nouveau/nouveau_fence.c |   11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -180,12 +180,11 @@ nouveau_fence_wait_uevent_handler(struct
 }
 
 static int
-nouveau_fence_wait_uevent(struct nouveau_fence *fence, bool intr)
-
+nouveau_fence_wait_uevent(struct nouveau_fence *fence,
+			  struct nouveau_drm *drm, bool intr)
 {
-	struct nouveau_channel *chan = fence->channel;
-	struct nouveau_fifo *pfifo = nouveau_fifo(chan->drm->device);
-	struct nouveau_fence_priv *priv = chan->drm->fence;
+	struct nouveau_fifo *pfifo = nouveau_fifo(drm->device);
+	struct nouveau_fence_priv *priv = drm->fence;
 	struct nouveau_fence_uevent uevent = {
 		.handler.func = nouveau_fence_wait_uevent_handler,
 		.priv = priv,
@@ -241,7 +240,7 @@ nouveau_fence_wait(struct nouveau_fence
 	int ret = 0;
 
 	while (priv && priv->uevent && lazy && !nouveau_fence_done(fence)) {
-		ret = nouveau_fence_wait_uevent(fence, intr);
+		ret = nouveau_fence_wait_uevent(fence, chan->drm, intr);
 		if (ret < 0)
 			return ret;
 	}


-- 
Jeff Mahoney
SUSE Labs

                 reply	other threads:[~2013-10-22 19:15 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=5266CEEC.2010606@suse.com \
    --to=jeffm@suse.com \
    --cc=bskeggs@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.