From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M9zhL-0008JI-Sa for qemu-devel@nongnu.org; Fri, 29 May 2009 06:52:27 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M9zhG-0008En-Oh for qemu-devel@nongnu.org; Fri, 29 May 2009 06:52:27 -0400 Received: from [199.232.76.173] (port=34556 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M9zhG-0008EX-GZ for qemu-devel@nongnu.org; Fri, 29 May 2009 06:52:22 -0400 Received: from mx2.redhat.com ([66.187.237.31]:58537) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M9zhF-0000Y2-UM for qemu-devel@nongnu.org; Fri, 29 May 2009 06:52:22 -0400 Message-ID: <4A1FBD9D.10400@redhat.com> Date: Fri, 29 May 2009 12:49:01 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] use qemu_malloc and friends consistently References: <200905290758.11551.jcd@tribudubois.net> <4A1F9FFE.3030100@redhat.com> <4A1FA573.4010602@codemonkey.ws> <4A1FB37E.5040602@redhat.com> <4A1FBA45.80902@redhat.com> In-Reply-To: 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: malc Cc: Paul Brook , qemu-devel@nongnu.org, Jean-Christophe Dubois malc schrieb: > On Fri, 29 May 2009, Kevin Wolf wrote: > >> malc schrieb: >>> On Fri, 29 May 2009, Kevin Wolf wrote: >>> >>>> malc schrieb: >>>>>> Putting the abort() in there is going to introduce a ton of subtle bugs, >>>>>> I vote for changing qemu_malloc() to have a sane behavior. >>>>> And those will be caught, given one a chance to analyze things, unlike >>>>> head in the sand approach of hoping things would just work. >>>>> >>>>> After doing some research, after the aforementioned lengthy discussion, >>>>> the only free OS that straight-forwardly described what it does was >>>>> OpenBSD: >>>>> >>>>> http://www.openbsd.org/cgi-bin/man.cgi?query=malloc&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html >>>>> >>>>> P.S. So far the abort that went into qemu_malloc caught one usage of zero >>>>> allocation (once again coming from qcow2). >>>> Zero allocation isn't a bug per se. Checking for NULL or dereferencing >>>> is. Any value that can be freed, be it NULL or anything else, was >>>> perfectly fine here without the abort() patch. So it actually was one of >>>> the subtle bugs Anthony mentioned which are introduced by the abort(). >>> And once again, the code would have aborted on AIX with our without abort >>> patch. The reason for abort is to identify and reason about all the call >>> sites that do that. >> Why would it have aborted? If AIX aborts on malloc(0), its malloc is >> seriously broken. But as I have understood from previous discussion, AIX >> just returns NULL. Would have been okay for this code. > > Because of oom_check in qemu_malloc. Ok, you're right there, of course. This is a bug in qemu_malloc and the reason why we even discussed changing the check in qemu_malloc. But this is not qcow2's fault, so the fix should really be local to qemu_malloc like it already was for qemu_realloc. Kevin