On Thu, Feb 27, 2014 at 04:11:39PM +0200, Ville Syrjälä wrote: > On Tue, Feb 25, 2014 at 02:23:28PM +0000, Chris Wilson wrote: > > In place of true activity counting, we walk the list of vma associated > > with an object managing each on the vm's active/inactive list everytime > > we call move-to-inactive. This depends upon the vma->mm_list being > > cleared after unbinding, or else we run into difficulty when tracking > > the object in multiple vm's - we see a use-after free and corruption of > > the mm_list. > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Ben Widawsky <ben@xxxxxxxxxxxx> > > --- > > drivers/gpu/drm/i915/i915_gem.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > > index 633a8d56e401..4de984e176f5 100644 > > --- a/drivers/gpu/drm/i915/i915_gem.c > > +++ b/drivers/gpu/drm/i915/i915_gem.c > > @@ -2874,7 +2874,7 @@ int i915_vma_unbind(struct i915_vma *vma) > > > > i915_gem_gtt_finish_object(obj); > > > > - list_del(&vma->mm_list); > > + list_del_init(&vma->mm_list); > > Isn't this just another symptom of the vma unbind recursion bug? I mean > how can someone else be accessing vma->mm_list while we're in the process > of freeing the vma itself (happens just a few lines down from here). We don't always free the vma along this path. Then we try to bind the vma in the second VM which hits the stale list entry. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
