From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=48389 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PzxEo-0008Lg-Jt
	for qemu-devel@nongnu.org; Wed, 16 Mar 2011 16:22:35 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1PzxEn-0006Kx-EP
	for qemu-devel@nongnu.org; Wed, 16 Mar 2011 16:22:34 -0400
Received: from mail-iy0-f173.google.com ([209.85.210.173]:55780)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1PzxEn-0006Ko-4r
	for qemu-devel@nongnu.org; Wed, 16 Mar 2011 16:22:33 -0400
Received: by iym7 with SMTP id 7so2325331iym.4
	for <qemu-devel@nongnu.org>; Wed, 16 Mar 2011 13:22:32 -0700 (PDT)
Message-ID: <4D811C02.2000109@codemonkey.ws>
Date: Wed, 16 Mar 2011 15:22:26 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [PATCH 21/26] Implement TCE translation for
	sPAPR VIO
References: <1300251423-6715-1-git-send-email-david@gibson.dropbear.id.au>	<1300251423-6715-22-git-send-email-david@gibson.dropbear.id.au>	<4D80DF6A.8040107@suse.de>
	<1300305919.22236.1175.camel@pasglop>
In-Reply-To: <1300305919.22236.1175.camel@pasglop>
Content-Type: text/plain; charset=UTF-8; format=flowed
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.nongnu.org/archive/html/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: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: David Gibson <david@gibson.dropbear.id.au>, paulus@samba.org, Alexander Graf <agraf@suse.de>, anton@samba.org, qemu-devel@nongnu.org

On 03/16/2011 03:05 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2011-03-16 at 17:03 +0100, Alexander Graf wrote:
>>> +int spapr_tce_dma_zero(VIOsPAPRDevice *dev, uint64_t taddr,
>> uint32_t size)
>>> +{
>>> +    uint8_t *zeroes;
>>> +
>>> +#ifdef DEBUG_TCE
>>> +    fprintf(stderr, "spapr_tce_dma_zero taddr=0x%llx size=0x%x\n",
>>> +            (unsigned long long)taddr, size);
>>> +#endif
>>> +
>>> +    /* FIXME: do this better... */
>>> +    zeroes = alloca(size);
>>> +    memset(zeroes, 0, size);
>> You sure that zeroes is still alive during the call? If I were a
>> compiler, I'd probably optimize the return away so that it'd end up
>> being a simple branch to spapr_tce_dma_write - coincidentally
>> invalidating the stack that zeroes is on.
> Ugh ? How would this ever be legal for a compiler to do that ?

But BTW, if you're already being evil and using alloca, it's a whole lot 
nicer to just do:

uint8_t zeros[size];

Regards,

Anthony Liguori

> Ben.
>
>
>