From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LUrdL-0001Nx-UZ for qemu-devel@nongnu.org; Wed, 04 Feb 2009 18:58:19 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LUrdL-0001Nj-3v for qemu-devel@nongnu.org; Wed, 04 Feb 2009 18:58:19 -0500 Received: from [199.232.76.173] (port=59059 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUrdL-0001Ne-1H for qemu-devel@nongnu.org; Wed, 04 Feb 2009 18:58:19 -0500 Received: from mx20.gnu.org ([199.232.41.8]:53058) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LUrdK-0007sO-Ly for qemu-devel@nongnu.org; Wed, 04 Feb 2009 18:58:18 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LUrdJ-00054W-Nn for qemu-devel@nongnu.org; Wed, 04 Feb 2009 18:58:18 -0500 From: Paul Brook Subject: Re: [Qemu-devel] Re: [PATCH 1/4] Add a scatter-gather list type and accessors Date: Wed, 4 Feb 2009 23:58:12 +0000 References: <1233750314-23301-1-git-send-email-avi@redhat.com> <4989FC3B.7010407@us.ibm.com> <4989FE92.5020400@redhat.com> In-Reply-To: <4989FE92.5020400@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902042358.13955.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Anthony Liguori , Avi Kivity > >>> Would be nice to check for malloc failures and fail gracefully at > >>> least. > >> > >> Do you mean an exit(1)? If so we could just put it in qemu_malloc(). > > > > In theory, some users may be able to cope with malloc failure. In > > practice, I don't think anyone can. I'm open to suggestion. > > malloc() will never fail on Linux with overcommit enabled; since Linux > is fairly useless without overcommit, it means you'll never see a failure. I disagree about "Linux is fairly useless without overcommit". Certain common linux applications maybe, however... > Other ways of allocating memory (stack growth, first access to anonymous > memory) are not covered. They can fail (most ungracefully) without > strict overcommit control. > > So I suggest to have qemu_malloc() and its friends abort on failure. I'll support this. In theory it's sometimes possible to recover from Out Of Memory conditions. However in practice I don't think there's any real scope for this in qemu. If were allocating huge chunks of ram on the fly then something else is already badly wrong. IMHO pushing the error up (down?) the callchain is unlikely to provide the user with significantly better information, we may as well bail out in qemu_malloc. Paul