Messages in this thread | | | Date | Fri, 13 Mar 2009 12:13:21 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH] x86: fix e820_update_range() |
| |
* 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
| |