dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <error27@gmail.com>
To: David Airlie <airlied@linux.ie>
Cc: Luca Barbieri <luca@luca-barbieri.com>,
	dri-devel@lists.freedesktop.org,
	Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: [patch] i915: take struct_mutex lock in intel_setup_overlay()
Date: Sat, 1 May 2010 00:27:57 +0200	[thread overview]
Message-ID: <20100430222757.GJ29093@bicker> (raw)

This is more of RFC than a proper patch.

I was looking at https://bugzilla.kernel.org/show_bug.cgi?id=15673 and I
wrote a script to show where we call drm_gem_object_unreference()
without holding struct_mutex and it showed these two places.

There call tree to here is:
i915_load_modeset_init()
    => intel_modeset_init()
           => intel_setup_overlay()

"reg_bo" is a local variable so we could probably leave that as
drm_gem_object_unreference() although I changed it in this patch.

The i915_gem_object_pin() function calls i915_gem_object_bind_to_gtt()
where we start unreferencing stuff if we're low on space.  So possibly
that lock is needed.  The call tree is:

i915_gem_object_pin()
    => i915_gem_object_bind_to_gtt()
        => i915_gem_evict_something()
            => i915_gem_retire_requests()
                => i915_gem_retire_request()
                    => drm_gem_object_unreference()

On the other hand, this is all in the module init so it seems like 
locking shouldn't be necessary, and certainly I can't see how it would 
cause the suspend bug.

I don't have this hardware btw, so I can't actually test this patch.

Signed-off-by: Dan Carpenter <error27@gmail.com>

diff --git a/drivers/gpu/drm/i915/intel_overlay.c b/drivers/gpu/drm/i915/intel_overlay.c
index 6d524a1..a103582 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -1347,7 +1347,9 @@ void intel_setup_overlay(struct drm_device *dev)
 	overlay->reg_bo = to_intel_bo(reg_bo);
 
 	if (OVERLAY_NONPHYSICAL(dev)) {
+		mutex_lock(&dev->struct_mutex);
 		ret = i915_gem_object_pin(reg_bo, PAGE_SIZE);
+		mutex_unlock(&dev->struct_mutex);
 		if (ret) {
                         DRM_ERROR("failed to pin overlay register bo\n");
                         goto out_free_bo;
@@ -1385,7 +1387,7 @@ void intel_setup_overlay(struct drm_device *dev)
 	return;
 
 out_free_bo:
-	drm_gem_object_unreference(reg_bo);
+	drm_gem_object_unreference_unlocked(reg_bo);
 out_free:
 	kfree(overlay);
 	return;

             reply	other threads:[~2010-04-30 22:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-30 22:27 Dan Carpenter [this message]
2010-05-03  7:58 ` [patch v2] i915: take struct_mutex lock in intel_setup_overlay() Dan Carpenter
2010-06-19 13:39   ` Dan Carpenter

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=20100430222757.GJ29093@bicker \
    --to=error27@gmail.com \
    --cc=airlied@linux.ie \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=luca@luca-barbieri.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