Re: [PATCH] x86: fix e820_update_range()

[Yinghai Lu <yinghai@kernel.org>]

Ingo Molnar wrote:
> * Jan Beulich <jbeulich@novell.com> wrote:
> 
>>>>> Yinghai Lu <yinghai@kernel.org> 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 <yinghai@kernel.org>
>>> ...
>>> +		/*
>>> +		 * 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