Re: [PATCH 1/4] [v2] drm/i915: Remove node only when allocated

[Ben Widawsky <ben@bwidawsk.net>]

On Thu, Aug 15, 2013 at 04:05:56PM +0200, Daniel Vetter wrote:
> On Wed, Aug 14, 2013 at 10:15:50AM +0200, Daniel Vetter wrote:
> > On Wed, Aug 14, 2013 at 10:06:30AM +0200, Daniel Vetter wrote:
> > > On Tue, Aug 13, 2013 at 06:09:06PM -0700, Ben Widawsky wrote:
> > > > VMAs can be created and not bound. One may think of it as lazy cleanup,
> > > > and safely gloss over the conditions which manufacture it. In either
> > > > case, when the object backing the i915 vma is destroyed, we must cleanup
> > > > the vma without stumbling into a bunch of pitfalls that assume the vma
> > > > is bound.
> > > > 
> > > > NOTE: I was pretty certain the above condition could only happen when we
> > > > introduced the use of VMAs being looked up at execbuf, and already
> > > > existing. Paulo has hit this though, so I must be missing something. As
> > > > I believe the patch is correct anyway, therefore I won't scratch my head
> > > > too hard.
> > > 
> > > If we end up calling evict_everything from i915_gem_object_bind_to_vm then
> > > we'll hit this. One more reason for a testcase here ;-) I'll amend the
> > > commit message and merge this. I've also applied a tiny bikeshed I've
> > > created while reviewing existing vma_create/destroy callsites.
> > 
> > Actually evict_everything isn't in the callpath, and there's no memory
> > allocation where the shrinker might play havoc. Furthermore the pages are
> > pinned so the shrinker shouldn't be able to sneak in at all. This is a bit
> > unsettling, I need to think more about this.
> > 
> > I'll wait with merging this for now.
> 
> Ok, I've merged the entire pile. I think now's the time to throw a bit of
> igt on top to exercise the corner cases here ...
> -Daniel

Was that a specific request for me to do something, I missed the message
if so? When should I rework the remaining patches and resend?

-- 
Ben Widawsky, Intel Open Source Technology Center