On ke, 2016-08-03 at 14:49 +0100, Chris Wilson wrote:
> 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).
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
> -Chris
>
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
