On Wed, Aug 03, 2016 at 04:43:38PM +0300, Joonas Lahtinen wrote:
> On ma, 2016-08-01 at 19:22 +0100, Chris Wilson wrote:
> > Inside the kthread context, we can't be interrupted by signals so
> > touching the mm.interruptible flag is pointless and wait-request now
> > consumes EIO itself.
> >
> > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > ---
> > drivers/gpu/drm/i915/i915_gem_userptr.c | 9 +--------
> > 1 file changed, 1 insertion(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > index 96ab6161903a..57218cca7e05 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > @@ -84,16 +84,9 @@ static void cancel_userptr(struct work_struct *work)
> > obj->userptr.work = NULL;
> >
> > if (obj->pages != NULL) {
> > - struct drm_i915_private *dev_priv = to_i915(dev);
> > - bool was_interruptible;
> > -
> > - was_interruptible = dev_priv->mm.interruptible;
> > - dev_priv->mm.interruptible = false;
> > -
>
> GEM_BUG_ON(dev_priv->mm.interruptible) too much paranoia?
It's inmaterial at this point whether or not that is set. That BUG is
something I've considered but never really found a good home. Best idea
I have is i915_mutex_lock_interruptible() (still it catches the victim
and not the guilty party, we need i915_mutex_unlock or something).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
