From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH libdrm 3/4] xf86drm: fix incorrect fd comparison in drmOpenOnce{,WithType} Date: Wed, 15 Jul 2015 13:47:24 +0200 Message-ID: <20150715114723.GC15045@ulmo.nvidia.com> References: <1436883005-6163-1-git-send-email-emil.l.velikov@gmail.com> <1436883005-6163-3-git-send-email-emil.l.velikov@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0485075791==" Return-path: Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by gabe.freedesktop.org (Postfix) with ESMTPS id AD3A06E15F for ; Wed, 15 Jul 2015 04:47:31 -0700 (PDT) Received: by pdbep18 with SMTP id ep18so24701611pdb.1 for ; Wed, 15 Jul 2015 04:47:31 -0700 (PDT) In-Reply-To: <1436883005-6163-3-git-send-email-emil.l.velikov@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Emil Velikov Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0485075791== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Y5rl02BVI9TCfPar" Content-Disposition: inline --Y5rl02BVI9TCfPar Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 14, 2015 at 03:10:04PM +0100, Emil Velikov wrote: > Spotted by looking for similar "let's assume fd =3D=3D 0 is invalid" bugs. >=20 > Cc: Thierry Reding > Signed-off-by: Emil Velikov > --- > xf86drm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/xf86drm.c b/xf86drm.c > index 2c17d11..39c6e2d 100644 > --- a/xf86drm.c > +++ b/xf86drm.c > @@ -2619,7 +2619,7 @@ int drmOpenOnceWithType(const char *BusID, int *new= lyopened, int type) > } > =20 > fd =3D drmOpenWithType(NULL, BusID, type); > - if (fd <=3D 0 || nr_fds =3D=3D DRM_MAX_FDS) > + if (fd < 0 || nr_fds =3D=3D DRM_MAX_FDS) Consider what happens if we have DRM_MAX_FDS file descriptors open and the call to drmOpenWithType() succeeds. We'll end up returning the file descriptor as is, but we won't keep track. I suppose this could have been on purpose, so that the device could be opened even if the file descriptor couldn't be cached anymore. One potential problem with that could be that the open-once restriction would be silently ignored. That may not be desirable. Thierry --Y5rl02BVI9TCfPar Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJVpkhIAAoJEN0jrNd/PrOhIeQP/iEu1KyrVoFaYtKn4XALYRXr p6ioWB4iv0Dt526Hgr8dep4A1BWR7163Ce155+Xh+fr7iclnMK4AG1DeeTSCldsi zfEtwwhynsyymd9K5Yi44LStu7R5a/6BxGWxWQS2F/Ae7vUpQH7sCFONoj4nxkEG c3m7EV05LTp0IgZJbsIlAj11lGE16mVAVVLFEFYAQUyySoNlzp8vZ8i79aNbYFXh ZqUA2WADg4tzT0Z1+Uetjk1Ru9MDp8PNHYt5V0SfD1tyTN6T9iCXJgtEM/xPQc+J 12Els2KA5kp5T/Ps/guH+O2z/C3zZlQxJVEAEo7IMiWDpmIaJnEpJQ0iiIZW76V7 a5ho9dnrU9aRm2sHi79zWQD7kluWgNr5xyj/Tq0UXnVmvFANIdCmEFfy1Tz/wiYS GU+680JE56yVCOfuGNkrrxZhKDWaHJNt26MtFIye60A+P4WB1uHKPBFPdsqoLtbG c20MCf0GOfy19nJ0Or0pr0c1JxkTZyxUULhx66ZwPOZ7JPXnpdak7jxZ0uRhZB3V 8L5BG/3EMh7rhm5MFOToNbu5jePH8kwX6/ZuEuo25KABeM3W+OzoMDzEOC6XGT9E Ba7H0ek3D3xcH2CD+OgRYxhX13X2pCCGj/V61RLljkK5acxVD8zCRMKcstxNBsee kaz+cCFLgMP/58Xvxqhz =Qfaf -----END PGP SIGNATURE----- --Y5rl02BVI9TCfPar-- --===============0485075791== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============0485075791==--