Messages in this thread | | | Date | Tue, 24 Jun 2008 13:49:48 +0800 | From | "Dave Young" <> | Subject | Re: [PATCH] kernel parameter vmalloc size fix |
| |
On Mon, Jun 16, 2008 at 4:01 PM, Ingo Molnar <mingo@elte.hu> wrote: > > * Dave Young <hidave.darkstar@gmail.com> wrote: > >> booting kernel with vmalloc=[any size<=16m] will oops. >> >> It's due to the vm area hole. >> >> In include/asm-x86/pgtable_32.h: >> #define VMALLOC_OFFSET (8 * 1024 * 1024) >> #define VMALLOC_START (((unsigned long)high_memory + 2 * VMALLOC_OFFSET - 1) \ >> & ~(VMALLOC_OFFSET - 1)) >> >> BUG_ON in arch/x86/mm/init_32.c will be triggered: >> BUG_ON((unsigned long)high_memory > VMALLOC_START); >> >> Fixed by return -EINVAL for invalid parameter > > hm. Why dont we instead add the size of the hole to the > __VMALLOC_RESERVE value instead? There's nothing inherently bad about > using vmalloc=16m. The VM area hole is really a kernel-internal > abstraction that should not be visible in the usage of the parameter.
I do some test about this last weekend, there's some questions, could you help to fix it?
1. MAXMEM : (-__PAGE_OFFSET - __VMALLOC_RESERVE). The space after VMALLOC_END is included as well, seting it to (VMALLOC_END - PAGE_OFFSET - __VMALLOC_RESERVE), is it right?
2. VMALLOC_OFFSET is not considered in __VMALLOC_RESERVE Should fixed by adding VMALLOC_OFFSET to it.
3. VMALLOC_START : (((unsigned long)high_memory + 2 * VMALLOC_OFFSET - 1) & ~(VMALLOC_OFFSET - 1)) So it's not always 8M, bigger than 8M possible. Set it to ((unsigned long)high_memory + VMALLOC_OFFSET), is it right?
Attached the proposed patch. please give some advice.
Regards dave [unhandled content-type:application/octet-stream] | |