From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH 1/2] drm/i915: Don't clobber the addfb2 ioctl params Date: Wed, 11 Nov 2015 19:24:40 +0200 Message-ID: <20151111172440.GL4437@intel.com> References: <1447261890-3960-1-git-send-email-ville.syrjala@linux.intel.com> <20151111172010.GI6247@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: <20151111172010.GI6247@nuc-i3427.alporthouse.com> Sender: stable-owner@vger.kernel.org To: Chris Wilson , intel-gfx@lists.freedesktop.org, Daniel Vetter , stable@vger.kernel.org, dri-devel@lists.freedesktop.org, Tvrtko Ursulin List-Id: intel-gfx@lists.freedesktop.org On Wed, Nov 11, 2015 at 05:20:10PM +0000, Chris Wilson wrote: > On Wed, Nov 11, 2015 at 07:11:28PM +0200, ville.syrjala@linux.intel.c= om wrote: > > From: Ville Syrj=E4l=E4 > >=20 > > We try to convert the old way of of specifying fb tiling (obj->tili= ng) > > into the new fb modifiers. We store the result in the passed in mod= e_cmd > > structure. But that structure comes directly from the addfb2 ioctl,= and > > gets copied back out to userspace, which means we're clobbering the > > modifiers that the user provided (all 0 since the DRM_MODE_FB_MODIF= IERS > > flag wasn't even set by the user). Hence if the user reuses the str= uct > > for another addfb2, the ioctl will be rejected since it's now askin= g for > > some modifiers w/o the flag set. >=20 > What do we actually pass back to userspace through the struct? The fb id. > Do we > just want to > -#define DRM_IOCTL_MODE_ADDFB2 DRM_IOWR(0xB8, struct drm_mod= e_fb_cmd2) > +#define DRM_IOCTL_MODE_ADDFB2 DRM_IOR(0xB8, struct drm_mode= _fb_cmd2 > instead? > -Chris >=20 > --=20 > Chris Wilson, Intel Open Source Technology Centre --=20 Ville Syrj=E4l=E4 Intel OTC