On Fri, Nov 18, 2016 at 01:31:57PM +0200, Joonas Lahtinen wrote:
> On pe, 2016-11-18 at 10:14 +0000, Chris Wilson wrote:
> > On Fri, Nov 18, 2016 at 11:18:09AM +0200, Joonas Lahtinen wrote:
> > > I don't quite see why? Are you expecting the iteration to hit same vma
> > > twice? Or somebody moving it while we iterate.
> >
> > The unbind may causes a free of any member on this list, so the pinning
> > prevents other vma from being unbound whilst waiting on this one. It
> > used to be a big deal, but since the various reworking the deferred free
> > hides the oops.
>
> Drop a comment.
/* Never show fear in the face of dragons!
*
* We cannot directly remove this node from within this
* iterator and as with i915_gem_evict_something() we employ
* the vma pin_count in order to prevent the action of
* unbinding one vma from freeing (by dropping its active
* reference) another in our eviction list. (Actually this
* *should* be safe now due to the independent retirement of
* vma and deferred free preventing other nodes from
* disappearing, but for consistency and that extra layer of
* warm protection, let it be!)
*/
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
