On Mon, Jul 18, 2016 at 11:18:27AM +0100, Chris Wilson wrote:
> On Fri, Jul 15, 2016 at 11:11:20AM +0100, Chris Wilson wrote:
> > @@ -1366,6 +1368,16 @@ i915_gem_object_wait_rendering(struct drm_i915_gem_object *obj,
> > GEM_BUG_ON(obj->active);
> > }
> >
> > + resv = i915_gem_object_get_dmabuf_resv(obj);
> > + if (resv) {
> > + long err;
> > +
> > + err = reservation_object_wait_timeout_rcu(resv, !readonly, true,
> > + MAX_SCHEDULE_TIMEOUT);
> > + if (err < 0)
> > + return err;
> > + }
>
> This introduces a potential WARN_ON into i915_gem_object_free() as the
> current i915_vma_unbind() calls i915_gem_object_wait_rendering(). To
> hit this path we first need to render with the GPU, have a dma-buf
> attached with an unsignaled fence and then interrupt the wait. It does
> get fixed later in the series (when i915_vma_unbind() only waits on the
> active VMA and not all, including third-party, rendering.
>
> It's only a WARN, so I don't think it is worth deferring it to after
> the vma fix is in place.
Adding the above in a FIXME comment right before the callt to
resv_obj_wait might be a good interim idea. But yes, given that prime
buffer sharing always resulted in lockdep unhappiness around struct_mutex,
horrible tearing and other sad things I don't think a temporary WARN_ON is
all that bad. Acked.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
