Re: Xen-unstable panic: FATAL PAGE FAULT

["Jan Beulich" <JBeulich@novell.com>]

>>> On 31.08.10 at 19:03, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
> On 31/08/2010 17:35, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote:
> 
>>> That's somewhat implicit: srat_parse_regions() gets passed an
>>> address that is at least BOOTSTRAP_DIRECTMAP_END (i.e. 4G).
>>> Thus srat_parse_regions() starts off with a mask with the lower
>>> 32 bits all set (only more bits can get set subsequently). Thus
>>> the earliest zero bit pfn_pdx_hole_setup() can find is bit 20
>>> (due to the >> PAGE_SHIFT in the invocation). Consequently
>>> the smallest chunk where arithmetic is valid really is 4Gb, not
>>> 256Mb as I first wrote.
>> 
>> Well, that's a bit too implicit for me. How about we initialise 'j' to
>> MAX_ORDER in pfn_pdx_hole_setup() with a comment about supporting page_info
>> pointer arithmetic within allocatable multi-page regions?
> 
> Well I agree with your logic anyway. So I don't see that this can be the
> cause of MaoXiaoyun's bug. At least not directly. But then I'm stumped as to
> why the page arithmetic and checks in free_heap_pages are (apparently)
> resulting in a page pointer way outside the frame-table region and actually
> in the directmap region.

There must be some unchecked use of PAGE_LIST_NULL, i.e.
running off a list end without taking notice (0xffff8315ffffffe4
exactly corresponds with that).

Jan