From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH 04/12] drm/i915: Don't unconditionally try to deref aliasing ppgtt Date: Mon, 25 Nov 2013 21:08:50 +0200 Message-ID: <20131125190850.GS10036@intel.com> References: <1385402083-8719-1-git-send-email-benjamin.widawsky@intel.com> <1385402083-8719-5-git-send-email-benjamin.widawsky@intel.com> <20131125180618.GI21316@nuc-i3427.alporthouse.com> <20131125181028.GB8797@bwidawsk.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTP id ABCF2FB0C0 for ; Mon, 25 Nov 2013 11:08:58 -0800 (PST) Content-Disposition: inline In-Reply-To: <20131125181028.GB8797@bwidawsk.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: Ben Widawsky Cc: Intel GFX , Ben Widawsky List-Id: intel-gfx@lists.freedesktop.org On Mon, Nov 25, 2013 at 10:10:28AM -0800, Ben Widawsky wrote: > On Mon, Nov 25, 2013 at 06:06:18PM +0000, Chris Wilson wrote: > > On Mon, Nov 25, 2013 at 09:54:35AM -0800, Ben Widawsky wrote: > > > Since the beginning, the functions which try to properly reference the > > > aliasing PPGTT have deferences a potentially null aliasing_ppgtt memb= er. > > > Since the accessors are meant to be global, this will not do. > > > = > > > Introduced originally in: > > > commit a70a3148b0c61cb7c588ea650db785b261b378a3 > > > Author: Ben Widawsky > > > Date: Wed Jul 31 16:59:56 2013 -0700 > > > = > > > drm/i915: Make proper functions for VMs > > > = > > > Signed-off-by: Ben Widawsky > > > --- > > > drivers/gpu/drm/i915/i915_gem.c | 6 ++++-- > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > = > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i= 915_gem.c > > > index 40d9dcf..bc5c865 100644 > > > --- a/drivers/gpu/drm/i915/i915_gem.c > > > +++ b/drivers/gpu/drm/i915/i915_gem.c > > > @@ -4971,7 +4971,8 @@ unsigned long i915_gem_obj_offset(struct drm_i9= 15_gem_object *o, > > > struct drm_i915_private *dev_priv =3D o->base.dev->dev_private; > > > struct i915_vma *vma; > > > = > > > - if (vm =3D=3D &dev_priv->mm.aliasing_ppgtt->base) > > > + if (!dev_priv->mm.aliasing_ppgtt || > > > + vm =3D=3D &dev_priv->mm.aliasing_ppgtt->base) > > = > > Where's the dereference? gcc is smarter than your average bear. > > -Chris > = > I had assumed: dev_priv->mm.aliasing_ppgtt->base in cases when > aliasing_ppgtt was NULL. Given that I never actually hit this, I agree > GCC must be doing something. Sounds like another discussion on the implementation of offsetof(). > = > Is such behavior documented somewhere? (forgive the lazy) IIRC the C standard does say that for &*foo it's as if both & and * weren't there (and IIRC the same for &foo[x]), but doesn't really say that kind of thing for &foo->bar. I guess it's a gray area, and just happens work that way on certain compilers. In this particular case I think there's one slight issue. If aliasing_pggtt =3D=3D NULL, and someone passes in vm =3D=3D NULL by accident, then it'll take the branch and use ggtt because &aliasing_ppgtt->base will be NULL too (due to base being at offset 0 in the struct). Now, I don't know if a NULL vm could survive this far into the code, but it it can, then it might make debugging a bit more "fun". As a side note, we actually depend on such things in the mode setting code. Ie. &((struct intel_crtc*)NULL)->base must be NULL, otherwise interesting bugs would happen. -- = Ville Syrj=E4l=E4 Intel OTC