On Tue, Feb 02, 2016 at 11:06:25AM +0000, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > > 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. > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > --- > drivers/gpu/drm/i915/i915_gem_stolen.c | 3 +++ > drivers/gpu/drm/i915/intel_display.c | 8 ++++++-- > 2 files changed, 9 insertions(+), 2 deletions(-) > > 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; I'm not keen on !mutex_is_locked(), since it can also just be another thread holding the struct_mutex that grants us protection from this check. At least lockdep checks that the caller holds the lock. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
