diff mbox

[08/13] drm/i915: GEM operations need to be done under the big lock

Message ID 1452252592-24803-9-git-send-email-tvrtko.ursulin@linux.intel.com (mailing list archive)
State New, archived
Headers show

Commit Message

Tvrtko Ursulin Jan. 8, 2016, 11:29 a.m. UTC 
From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

VMA creation and GEM list management need the big lock.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 drivers/gpu/drm/i915/i915_gem_stolen.c | 5 +++++
 1 file changed, 5 insertions(+)

Comments

Chris Wilson Jan. 8, 2016, 11:40 a.m. UTC | #1 
On Fri, Jan 08, 2016 at 11:29:47AM +0000, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> 
> VMA creation and GEM list management need the big lock.

No, this operation doesn't require locking.
-Chris
Chris Wilson Jan. 8, 2016, 11:45 a.m. UTC | #2 
On Fri, Jan 08, 2016 at 11:40:56AM +0000, Chris Wilson wrote:
> On Fri, Jan 08, 2016 at 11:29:47AM +0000, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > 
> > VMA creation and GEM list management need the big lock.
> 
> No, this operation doesn't require locking.

My bad, there's a vm->list tracking. I was thinking of the
obj->vma_list.
-Chris
Tvrtko Ursulin Jan. 8, 2016, 11:47 a.m. UTC | #3 
On 08/01/16 11:40, Chris Wilson wrote:
> On Fri, Jan 08, 2016 at 11:29:47AM +0000, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>
>> VMA creation and GEM list management need the big lock.
>
> No, this operation doesn't require locking.

You can argue about positioning and such, but it is adding it to the 
bound and inactive list...

Tvrtko
Chris Wilson Jan. 8, 2016, 12:09 p.m. UTC | #4 
On Fri, Jan 08, 2016 at 11:47:03AM +0000, Tvrtko Ursulin wrote:
> 
> On 08/01/16 11:40, Chris Wilson wrote:
> >On Fri, Jan 08, 2016 at 11:29:47AM +0000, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >>
> >>VMA creation and GEM list management need the big lock.
> >
> >No, this operation doesn't require locking.
> 
> You can argue about positioning and such, but it is adding it to the
> bound and inactive list...

Actually you raise a good point about the other stolen series,
namely we need to push this lock up to the caller since we have the
samme issue wit i915_gem_object_create_stolen() which I don't remember
that we fixed in valleyview_setup_pctx().
-Chris
diff mbox

Patch

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
index c384dc9c8a63..16cab255fa6c 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -670,9 +670,12 @@  i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
 	if (gtt_offset == I915_GTT_OFFSET_NONE)
 		return obj;
 
+	mutex_lock(&dev->struct_mutex);
+
 	vma = i915_gem_obj_lookup_or_create_vma(obj, ggtt);
 	if (IS_ERR(vma)) {
 		ret = PTR_ERR(vma);
+		mutex_unlock(&dev->struct_mutex);
 		goto err;
 	}
 
@@ -698,6 +701,8 @@  i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
 	list_add_tail(&obj->global_list, &dev_priv->mm.bound_list);
 	i915_gem_object_pin_pages(obj);
 
+	mutex_unlock(&dev->struct_mutex);
+
 	return obj;
 
 err: