Re: [PATCH 04/16] drm/i915/userptr: Remove superfluous interruptible=false on waiting

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux