From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49292) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmoyV-0006f8-Oq for qemu-devel@nongnu.org; Mon, 16 Jan 2012 11:00:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RmoyL-0003gm-9y for qemu-devel@nongnu.org; Mon, 16 Jan 2012 10:59:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:32854) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmoyK-0003eQ-11 for qemu-devel@nongnu.org; Mon, 16 Jan 2012 10:59:48 -0500 Message-ID: <4F14496F.8020500@redhat.com> Date: Mon, 16 Jan 2012 08:59:43 -0700 From: Eric Blake MIME-Version: 1.0 References: <1326482122-12619-1-git-send-email-lcapitulino@redhat.com> <1326482122-12619-3-git-send-email-lcapitulino@redhat.com> <4F10A694.8030900@redhat.com> <20120116105140.GA7180@jl-vm1.vm.bytemark.co.uk> In-Reply-To: <20120116105140.GA7180@jl-vm1.vm.bytemark.co.uk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig32063F5EEB48753593E770ED" Subject: Re: [Qemu-devel] [PATCH 2/2] qemu-ga: Add the guest-suspend command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: mdroth@linux.vnet.ibm.com, jcody@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig32063F5EEB48753593E770ED Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 01/16/2012 03:51 AM, Jamie Lokier wrote: >=20 > Since you mention async-signal-safety, execlp() isn't > async-signal-safe! Last time I checked, in Glibc execlp() could call > malloc(). Also reading PATH looks at the environment, which isn't > always thread-safe either, depending on what else is going on. That's why I questioned the use of a PATH lookup in the child. Doing a PATH lookup in the parent, then using an absolute name in the execle() of the child, is indeed better. >=20 > I'm not sure if it's relevant to the this code, but on Glibc fork() is > not async-signal-safe and has been known to crash in signal handlers. > This is why fork() was removed from SUS async-signal-safe functions. fork() is still in the list of async-signal-safe functions [1]; it was only pthread_atfork() which was removed. That is, fork() is _required_ to be async-signal-safe (and usable from signal handlers), provided that the actions following the fork also follow safety rules. [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#= tag_15_04_03 >=20 >> I didn't check whether slog() is async-signal safe (probably not, sinc= e >> even snprintf() is not async-signal safe, and you are passing a printf= >> style format string). But strerror() is not, so you shouldn't be usin= g >> it in the child if qemu-ga is multithreaded. >=20 > In general, why is multithreadedness relevant to async-signal-safety he= re? Because POSIX 2008 (SUS inherits from POSIX, so it has the same restriction) states that if a multithreaded app calls fork, the child can only portably use async-signal-safe functions up until a successful exec or _exit. Even though the child is _not_ operating in a signal handler context, it _is_ operating in a context of a single thread where other threads from the parent may have been holding locks, and thus calling any unsafe function (that is, any function that tries to obtain a lock) may deadlock. I don't know if qemu-ga is intended to be a multi-threaded app, so I don't know if being paranoid about async-signal-safety matters in this particular case, but I _do_ know that libvirt has encountered issues with using non-safe functions prior to exec, which is why it always raises red flags when I see unsafe code between fork and exec. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig32063F5EEB48753593E770ED Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPFElvAAoJEKeha0olJ0NqxB0H/1qAToB+j1OfzcHsjBG3NCzd kwQqTnIA+/WjGZ7yB/ZZWxWq5cUYgYwLrl0hobz29RA7GYzF5lHDDXoct/bBU19E 1eYFOhOIZz6nwxdxHQCxBlAD32yY++7HjlA4tqrBu613kyKSA1X4C/D8/M/W3JsI YkhlJ0oVLYMNa9gTSLnLKwvOPOCflFzUzlceVH/XOva/ILIaYXrKDcBpLKP10pMF 5iuFj0DJap4wqOIHTdbzJ1U2qBMAM1Q4ureAOwgcvWsMfn0FxmC7EK23uhN21A0x XrTiGZ048EzCVqqskvZfMi3yJyC83Gbu1MO+eNEfo2wqfXD9aWeXLCvyjjdskiw= =s2MM -----END PGP SIGNATURE----- --------------enig32063F5EEB48753593E770ED--