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;
next 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