From mboxrd@z Thu Jan  1 00:00:00 1970
From: Shannon Zhao <shannon.zhao@linaro.org>
Subject: Re: xen/arm: Crash when allocating memory for ACPI
 table (Was Re: Design doc of adding ACPI support for arm64 on Xen - version
 2)
Date: Fri, 14 Aug 2015 22:55:56 +0800
Message-ID: <55CE017C.6070405@linaro.org>
References: <55C413D5.7000709@huawei.com>	<55CAF41C.1090208@huawei.com>	<55CB0DC0.4020304@citrix.com>	<55CDF5A3.8050201@linaro.org>
	<55CDF87C.40103@citrix.com> <55CDFCBD.608@linaro.org>
	<55CDFE20.3070208@citrix.com> <55CDFFFB.5070707@linaro.org>
	<55CE00DD.8020303@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <55CE00DD.8020303@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Julien Grall <julien.grall@citrix.com>, Shannon Zhao <zhaoshenglong@huawei.com>, xen-devel <xen-devel@lists.xen.org>, Jan Beulich <jbeulich@suse.com>, Stefano Stabellini <stefano.stabellini@citrix.com>, Ian Campbell <ian.campbell@citrix.com>, Parth Dixit <parth.dixit@linaro.org>, Christoffer Dall <christoffer.dall@linaro.org>
Cc: Hangaohuai <hangaohuai@huawei.com>, "Huangpeng (Peter)" <peter.huangpeng@huawei.com>
List-Id: xen-devel@lists.xenproject.org



On 2015/8/14 22:53, Julien Grall wrote:
> On 14/08/15 15:49, Shannon Zhao wrote:
>>> Ok, so it's likely a memory corruption. You need to check the bound you
>>> ara using when copying the data to the guest or from the ACPI in
>>> general. Or maybe you just didn't allocate enough space.
>>>
>>
>> But it fails at the xzalloc_bytes itself. not at copy function.
>
> Because the previous copy may have overwritten the metadata of the
> memory allocator...
>
> If those metadata are corrupted, xalloc_bytes we act weirdly such as
> crashing Xen.
>
Ok, will check it. Thanks.

-- 
Shannon