Re: [PATCH] x86: fix e820_update_range()

[Ingo Molnar <mingo@elte.hu>]

* 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.

	Ingo