[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49BAA454.3050100@kernel.org>
Date: Fri, 13 Mar 2009 11:22:12 -0700
From: Yinghai Lu <yinghai@...nel.org>
To: Ingo Molnar <mingo@...e.hu>
CC: Jan Beulich <jbeulich@...ell.com>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: fix e820_update_range()
Ingo Molnar wrote:
> * Jan Beulich <jbeulich@...ell.com> wrote:
>
>>>>> Yinghai Lu <yinghai@...nel.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@...nel.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists