| Message ID | 1452521321-4032-8-git-send-email-tvrtko.ursulin@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Jan 11, 2016 at 02:08:41PM +0000, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > > VMA creation and GEM list management need the big lock. > > v2: > > Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall) > > Not to mention drm_gem_object_unreference was there in existing > code with no mutex held. > > v3: > > Some callers of i915_gem_object_create_stolen_for_preallocated > already hold the lock so move the mutex into the other caller > as well. intel_pm.c valleyview_setup_pctx? -Chris
On 11/01/16 14:38, Chris Wilson wrote: > On Mon, Jan 11, 2016 at 02:08:41PM +0000, Tvrtko Ursulin wrote: >> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com> >> >> VMA creation and GEM list management need the big lock. >> >> v2: >> >> Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall) >> >> Not to mention drm_gem_object_unreference was there in existing >> code with no mutex held. >> >> v3: >> >> Some callers of i915_gem_object_create_stolen_for_preallocated >> already hold the lock so move the mutex into the other caller >> as well. > > intel_pm.c valleyview_setup_pctx? Already holds it traced by the WARN_ON at its top. Regards, Tvrtko
On Mon, Jan 11, 2016 at 02:47:17PM +0000, Tvrtko Ursulin wrote: > > On 11/01/16 14:38, Chris Wilson wrote: > >On Mon, Jan 11, 2016 at 02:08:41PM +0000, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > >> > >>VMA creation and GEM list management need the big lock. > >> > >>v2: > >> > >>Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall) > >> > >>Not to mention drm_gem_object_unreference was there in existing > >>code with no mutex held. > >> > >>v3: > >> > >>Some callers of i915_gem_object_create_stolen_for_preallocated > >>already hold the lock so move the mutex into the other caller > >>as well. > > > >intel_pm.c valleyview_setup_pctx? > > Already holds it traced by the WARN_ON at its top. Which is a nice little mutex inversion of its own. :| i.e. rpm vs struct_mutex bug -Chris
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c index c384dc9c8a63..a97a5e762c0f 100644 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c @@ -635,6 +635,9 @@ i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev, if (!drm_mm_initialized(&dev_priv->mm.stolen)) return NULL; + if (WARN_ON_ONCE(!mutex_is_locked(&dev->struct_mutex))) + return NULL; + DRM_DEBUG_KMS("creating preallocated stolen object: stolen_offset=%x, gtt_offset=%x, size=%x\n", stolen_offset, gtt_offset, size); diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index b4cf9ce16155..073d6c99406b 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2534,12 +2534,16 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc, if (size_aligned * 2 > dev_priv->gtt.stolen_usable_size) return false; + mutex_lock(&dev->struct_mutex); + obj = i915_gem_object_create_stolen_for_preallocated(dev, base_aligned, base_aligned, size_aligned); - if (!obj) + if (!obj) { + mutex_unlock(&dev->struct_mutex); return false; + } obj->tiling_mode = plane_config->tiling; if (obj->tiling_mode == I915_TILING_X) @@ -2552,12 +2556,12 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc, mode_cmd.modifier[0] = fb->modifier[0]; mode_cmd.flags = DRM_MODE_FB_MODIFIERS; - mutex_lock(&dev->struct_mutex); if (intel_framebuffer_init(dev, to_intel_framebuffer(fb), &mode_cmd, obj)) { DRM_DEBUG_KMS("intel fb init failed\n"); goto out_unref_obj; } + mutex_unlock(&dev->struct_mutex); DRM_DEBUG_KMS("initial plane fb obj %p\n", obj);