From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHa4k-0001R8-Uh for qemu-devel@nongnu.org; Mon, 07 Dec 2009 04:40:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHa4j-0001QU-KY for qemu-devel@nongnu.org; Mon, 07 Dec 2009 04:40:14 -0500 Received: from [199.232.76.173] (port=37427 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHa4j-0001QR-E5 for qemu-devel@nongnu.org; Mon, 07 Dec 2009 04:40:13 -0500 Received: from bhuna.collabora.co.uk ([93.93.128.226]:36672) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NHa4j-0001c3-2z for qemu-devel@nongnu.org; Mon, 07 Dec 2009 04:40:13 -0500 Message-ID: <4B1CCD4F.3030003@collabora.co.uk> Date: Mon, 07 Dec 2009 09:39:27 +0000 From: Ian Molton MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends References: <4B193DA5.6040507@codemonkey.ws> <4B1A9359.8080305@redhat.com> <4B1A9811.8020108@codemonkey.ws> <4B1BE153.6070509@collabora.co.uk> <4B1BE691.1010401@redhat.com> <4B1BF1A0.4030002@redhat.com> <4B1C3282.70009@collabora.co.uk> <20091207025156.GD1021@shareable.org> In-Reply-To: <20091207025156.GD1021@shareable.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: qemu-devel@nongnu.org, Paul Brook , Avi Kivity , Markus Armbruster Jamie Lokier wrote: > If the system as a whole runs out of memory so that no-overcommit > malloc() fails on a small alloc, there's a good chance that you won't > be able to send a message to the host Send what message to the host? If the malloc in the socet reconnect code fails, its the code on the host thats going to flag up that malloc failed. > and if it does manage to receive the message, you can be almost > certain that it won't be able to run any GUI operations, send mail, > etc. to inform the admin. OTOH, If all it does it log it to a file, theres a fair chance it might succeed. > There's no point writing the code for the first steps, if it's > intractable to make the later steps do something useful. OTOH, a simple printed warning, and closing the socket are fairly likely to work. > Btw, as an admin I would really rather the socket reconnection code > keeps trying in that circumstance, if qemu does not simply fall over > due to alloc failing for something else soon after. Surely better to keep running by dropping nonessential services so that the guest might get a chance to shut down or the host might recover. > I'd rather it behaves like a broken HWRNG if it can't get host > entropy: Don't provide data, and let the guest decide what to do, just > like it does for a broken HWRNG. It does. > Except virtio-rng can report unavailability rather than simply being broken :-) It could, in theory. -Ian