From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NHvzB-0007AE-7c
	for qemu-devel@nongnu.org; Tue, 08 Dec 2009 04:03:57 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NHvz6-00075w-3m
	for qemu-devel@nongnu.org; Tue, 08 Dec 2009 04:03:56 -0500
Received: from [199.232.76.173] (port=58505 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NHvz5-00075q-Tx
	for qemu-devel@nongnu.org; Tue, 08 Dec 2009 04:03:51 -0500
Received: from mx1.redhat.com ([209.132.183.28]:43812)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kwolf@redhat.com>) id 1NHvz4-00056t-S2
	for qemu-devel@nongnu.org; Tue, 08 Dec 2009 04:03:51 -0500
Message-ID: <4B1E161C.9070801@redhat.com>
Date: Tue, 08 Dec 2009 10:02:20 +0100
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends
References: <m3skbwxgkp.fsf@crossbow.pond.sub.org>
	<4B1D2462.3070000@codemonkey.ws>
	<Pine.LNX.4.64.0912071955070.2225@linmac.oyster.ru>
	<4B1D34E2.6010109@codemonkey.ws>
	<Pine.LNX.4.64.0912072003310.2349@linmac.oyster.ru>
In-Reply-To: <Pine.LNX.4.64.0912072003310.2349@linmac.oyster.ru>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: malc <av1474@comtv.ru>
Cc: Avi Kivity <avi@redhat.com>, Paul Brook <paul@codesourcery.com>, Markus Armbruster <armbru@redhat.com>, qemu-devel@nongnu.org

Am 07.12.2009 18:09, schrieb malc:
> On Mon, 7 Dec 2009, Anthony Liguori wrote:
> 
>> malc wrote:
>>>> Does anyone object to this moving forward?
>>>>     
>>>
>>> Yeah, i object to the split production/development qemu_malloc[z].
>>>   
>>
>> It's clear to me that there are still improper callers of qemu_malloc() in the
>> tree.  How do you propose we address this for 0.12?
>>
>> Aborting in a production build is a rather hostile thing to do if it can be
>> avoided.
> 
> The only real issue encountered so far was eb0b64f7a, there are claims
> that "maybe there are more", 

702ef63f was the one that started this discussion. And Markus had list
of five other places that can very likely crash with the abort. Every
single crash is one crash too much in a production environment. Turning
the abort off is the only sane option there.

Having the abort in place in the development branch is a concession to
you. Crashes don't have as bad impact there, so we probably can afford
it. I'm fine with that as long as there is a plan to move forward to a
better API.

> well i can also claim that there are abusers
> of the interface that just weren't encoutered yet,

Right, but have you found a single one of them yet? If not, in terms of
committed patches the score is 4:0 for legitimate users broken by
abort() vs. abusers found by abort().

Kevin