Hi,
The current 2.6.18-xen tree''s kexec seems to be working for me OK on
x86_64 and on small i686 boxes, but it is broken on >1GB 32-bit
configurations, oopsing when the kexec kernel is set up with:
BUG: unable to handle kernel NULL pointer dereference at virtual address
00000000
...
CPU: 0
EIP: 0061:[<c0415550>] Not tainted VLI
EFLAGS: 00010216 (2.6.18-20.el5.kraxel.7xen #1)
EIP is at xen_create_contiguous_region+0x9c/0x44b
eax: 00000000 ebx: 00001000 ecx: 00000400 edx: 00000000
esi: 0000000b edi: 00000000 ebp: 00000001 esp: ea292e90
ds: 007b es: 007b ss: 0069
Process kexec (pid: 2439, ti=ea292000 task=ea577aa0 task.ti=ea292000)
...
Call Trace:
[<c044ac8f>] get_page_from_freelist+0x1c1/0x325
[<c044fc72>] page_address+0x7a/0x81
[<c0438f04>] kimage_alloc_pages+0x64/0xa2
[<c0438fdf>] kimage_alloc_page+0x9d/0x2a5
[<c0439226>] kimage_add_entry+0x3f/0xbd
[<c0439780>] sys_kexec_load+0x2a0/0x3f7
[<c040534f>] syscall_call+0x7/0xb
======================
I''m using the kexec code back-ported to the RHEL-5 kernel atm, but
current xen-unstable.hg appears to have the same problem.
The problem is in kimage_alloc_pages(), which tries to return contiguous
pages by calling
xen_create_contiguous_region((unsigned long)page_address(pages),
order, address_bits)
on the pages allocated. Unfortunately, page_address() returns NULL for
highmem pages. So as soon as we try this on a page in the highmem heap,
we get the above OOPS.
Fortunately it''s easy to fix: we don''t need to call
xen_create_contiguous_region() on highmem pages, because the only place
I can see in kexec which uses GFP_HIGHMEM also allocates only single
pages at a time (and those are by definition always contiguous anyway!)
So we really only need to call xen_(create|destroy)_contiguous_region()
if order>0. That will continue to do the right thing for lowmem high-
order allocations, while allowing single-page GFP_HIGHEM allocations to
work.
The patch below fixes this for me.
--Stephen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On Mon, 2007-06-18 at 15:29 +0100, Stephen C. Tweedie wrote:> The problem is in kimage_alloc_pages(), which tries to return contiguous > pages by calling > > xen_create_contiguous_region((unsigned long)page_address(pages), > order, address_bits) > > on the pages allocated. Unfortunately, page_address() returns NULL for > highmem pages. So as soon as we try this on a page in the highmem heap, > we get the above OOPS.The intention of this call is actually to ensure that the MFNs are below the limit imposed by the limit argument rather than to make a contiguous region so it is still required for order 0 allocations. Without this guarantee trying to load a crash kernel results in an OOM due to the check of mfn vs KEXEC_CONTROL_MEMORY_LIMIT in kimage_alloc_normal_control_pages(). There is similar check vs KEXEC_SOURCE_MEMORY_LIMIT in kimage_alloc_page(). It''s possible (even likely with large hosts) for a domain to have no pages which satisfy these constraints so without the xen_create_contiguous_region it sucks up all memory and OOMs. This was introduced with xen-unstable.hg 14372:a1daade92952 I guess xen_create_contiguous_region is happy to operate on a temporarily kmapped page which are immediately unmapped since we only care that the MFN has been moved below the limit. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, 2007-06-18 at 16:11 +0100, Ian Campbell wrote:> I guess xen_create_contiguous_region is happy to operate on a > temporarily kmapped page which are immediately unmapped since we only > care that the MFN has been moved below the limit.Turns out this is not the case, x_c_c_r doesn''t work for highmem and kmap gets very upset if the p2m mapping changes under its feet. I think 78:0be610b725fa in the linux-2.6.18-xen.hg staging tree addresses the issue. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel