From mboxrd@z Thu Jan 1 00:00:00 1970 From: Imre Deak Subject: Re: [PATCH] lib/drmtest: don't use asprintf on signal paths Date: Wed, 05 Feb 2014 11:29:18 +0200 Message-ID: <1391592558.30971.37.camel@intelbox> References: <1391541314-18771-1-git-send-email-imre.deak@intel.com> <20140204212929.GJ11603@nuc-i3427.alporthouse.com> <1391551486.3416.14.camel@ideak-mobl> <20140204231946.GC17001@phenom.ffwll.local> Reply-To: imre.deak@intel.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1181584676==" Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTP id 1FAF61057D0 for ; Wed, 5 Feb 2014 01:29:21 -0800 (PST) In-Reply-To: <20140204231946.GC17001@phenom.ffwll.local> 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: Daniel Vetter Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============1181584676== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-X7dMrUgITToJwbLyKfSH" --=-X7dMrUgITToJwbLyKfSH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2014-02-05 at 00:19 +0100, Daniel Vetter wrote: > On Wed, Feb 05, 2014 at 12:04:46AM +0200, Imre Deak wrote: > > On Tue, 2014-02-04 at 21:29 +0000, Chris Wilson wrote: > > > On Tue, Feb 04, 2014 at 09:15:14PM +0200, Imre Deak wrote: > > > > It's not signal safe and I got kms_flip in hung state with the back= trace > > > > below, while the parent process waiting for the signal helper to ex= it. > > > > It was quite easy to reproduce the bug by running > > > >=20 > > > > kms_flip --run-subtest=3Dflip-vs-dpms-off-vs-modeset > > >=20 > > > snprintf is not signalsafe either (man 7 signal). X goes as far as > > > implementing its own limited pnprintf() instead. > >=20 > > Thanks. I got only as far as to realize that asprintf is not signal-saf= e > > b/c of malloc and didn't remember any place with an official list of > > allowed functions.. > >=20 > > I also missed at least igt_skip() calling vprintf(), so this needs some > > more thought. >=20 > Hm, what calls igt_skip from exit handlers? That would be a fairly big bu= g > in the framework ... If it happens atm I guess we should splatter a few > more asserts all over the place. At least quiescent_gpu_at_exit()->__drm_open_any()->drm_get_card(). > For the actual issue at hand I dunno what to do. Trying to keep all exit > handlers signal-save seems like a lost cause since we'll always miss some > of them because normally they run as atexit callbacks. And libc isn't > friendly and tells us when we do something stupid. Overall this feels a > bit like a general reliability nightmare :( Yea, doing anything substantial in signal handlers doesn't seem like a good idea. I haven't found much info about what functions you can call from exit handlers, but I guess we should treat that case similarly to signal handlers. I think the only clean, safe and maintainable way is to run the actual test in a forked process and do any cleanup in case of error or normal exit in the parent wrapper process. We wouldn't install any cleanup signal handlers in the child (children), just let it die and have the wrapper process cleanup afterwards. If a signal handler for cleanup would be unavoidable it would be really simple and just communicate anything necessary to the wrapper so that it can do the actual cleanup. Forking helpers would happen with the control of the wrapper, using some IPC like a pipe/socket, where the wrapper would receive the pid of any newly forked helper and it could make sure none of those are left behind at exit. I would also use a different method for the (normal) termination of forked helpers. Atm, we do kill(SIGQUIT), but using some IPC (pipe) would be more robust imo. But, for the short term I would suggest auditing our current atexit handlers, and making them signal-safe. There are about 10 of those, so it's not (yet) unsurmountable. --Imre --=-X7dMrUgITToJwbLyKfSH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAABAgAGBQJS8gRuAAoJEORIIAnNuWDFtXAH/iOlgpy1Rl43KSHbm/P57YUE W2iaGnYaVkkZE79KpRGFV9fLv5xhjgba+2jTdPabV15Py//gFNSgUiXRApnqYOn2 o6EtlUonvJzIBkIreWKHOwYsvJNTYHBNry3d0v2Lg0pyIAWhiIevf8K64UTtkrUj KH0IVM28WtS6e9TBxKQmPIpikOBkA4TVqLFdLVxYzpicU+yEbRctRyZ1/W27yVbC LlJhDZnY4NBEKL9txUgd7wru7ppLh0VBrwG7KtmkAzNt3bq2VjZWX+42yhwnFDtY 7BGY40yQjvkicoqjb3qibPpaudY4vD3FWbHO70I3aFR9vU9im/hK3YCOipPeeCg= =Zsc9 -----END PGP SIGNATURE----- --=-X7dMrUgITToJwbLyKfSH-- --===============1181584676== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============1181584676==--