From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758732AbZCMSXV (ORCPT ); Fri, 13 Mar 2009 14:23:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757968AbZCMSXK (ORCPT ); Fri, 13 Mar 2009 14:23:10 -0400 Received: from hera.kernel.org ([140.211.167.34]:44997 "EHLO hera.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758096AbZCMSXJ (ORCPT ); Fri, 13 Mar 2009 14:23:09 -0400 Message-ID: <49BAA454.3050100@kernel.org> Date: Fri, 13 Mar 2009 11:22:12 -0700 From: Yinghai Lu User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: Ingo Molnar CC: Jan Beulich , Thomas Gleixner , "H. Peter Anvin" , linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86: fix e820_update_range() References: <49B914B6.76E4.0078.0@novell.com> <49B9E286.502@kernel.org> <49BA1FFC.76E4.0078.0@novell.com> <20090313111321.GA19523@elte.hu> In-Reply-To: <20090313111321.GA19523@elte.hu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ingo Molnar wrote: > * Jan Beulich wrote: > >>>>> Yinghai Lu 13.03.09 05:35 >>> >>> Impact: fix left range size on head. >>> >>> | commit 5c0e6f035df983210e4d22213aed624ced502d3d >>> | x86: fix code paths used by update_mptable >>> | Impact: fix crashes under Xen due to unrobust e820 code >>> fix one bug about e820 referring, but introduce other bug >>> >>> need update size for left range at first in case it is header. >>> >>> also add __e820_add_region take more parameter. >>> >>> Signed-off-by: Yinghai Lu >>> ... >>> + /* >>> + * left range could be head or tail, so need to update >>> + * size at first. >>> + */ >>> + ei->size -= final_end - final_start; >>> if (ei->addr < final_start) >>> continue; >>> ei->addr = final_end; >>> - ei->size -= final_end - final_start; >> The change of mine here was done on purpose, since I had >> observed that in this particular case (when the changed region >> starts later and ends earlier than the original region) >> e820_add_region() would in any case create an overlapping >> entry (which later gets cleaned up by sanitize_e820_map()). >> That cleanup in sanitize_e820_map(), however, already implies >> reducing the size of the enclosing region, and hence the >> original code (and the code you try to restore now) >> effectively shrinks the original region twice. >> >> Consequently, the only alternative to the code as resulting >> from my patch appears to be to avoid the generation of >> overlapping entries in the first place, but that would clearly >> make e820_update_range_map() more complex. > > Still that looks like the best course of action - the core e820 > primitives should always produce a sane map. > yesterday i sent out [PATCH] x86: make e820_update_range to handle small range update YH