Re: [RFC 04/44] drm/i915: Fix null pointer dereference in error capture

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

 



On Tue, Jul 01, 2014 at 08:12:11AM +0100, Chris Wilson wrote:
> On Mon, Jun 30, 2014 at 02:40:05PM -0700, Jesse Barnes wrote:
> > On Thu, 26 Jun 2014 18:23:55 +0100
> > John.C.Harrison@xxxxxxxxx wrote:
> > 
> > > From: John Harrison <John.C.Harrison@xxxxxxxxx>
> > > 
> > > The i915_gem_record_rings() code was unconditionally querying and saving state
> > > for the batch_obj of a request structure. This is not necessarily set. Thus a
> > > null pointer dereference can occur.
> > > ---
> > >  drivers/gpu/drm/i915/i915_gpu_error.c |   13 +++++++------
> > >  1 file changed, 7 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c
> > > index 87ec60e..0738f21 100644
> > > --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> > > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> > > @@ -902,12 +902,13 @@ static void i915_gem_record_rings(struct drm_device *dev,
> > >  			 * as the simplest method to avoid being overwritten
> > >  			 * by userspace.
> > >  			 */
> > > -			error->ring[i].batchbuffer =
> > > -				i915_error_object_create(dev_priv,
> > > -							 request->batch_obj,
> > > -							 request->ctx ?
> > > -							 request->ctx->vm :
> > > -							 &dev_priv->gtt.base);
> > > +			if(request->batch_obj)
> > > +				error->ring[i].batchbuffer =
> > > +					i915_error_object_create(dev_priv,
> > > +								 request->batch_obj,
> > > +								 request->ctx ?
> > > +								 request->ctx->vm :
> > > +								 &dev_priv->gtt.base);
> > >  
> > >  			if (HAS_BROKEN_CS_TLB(dev_priv->dev) &&
> > >  			    ring->scratch.obj)
> > 
> > Reviewed-by: Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx>
> 
> Nah, put the NULL check into the macro. i915_error_object_create() was
> originally written as a no-op on NULL pointers for cleanliness, we may
> as well do the check centrally and remove the extras we have grown.

Also the usual broken record from your maintainer: How does this blow up
and can we please have a testcase for it? Oscar provided a basic error
state check test, so the infrastructure for a new subtest is now there. I
hope ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://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