lkml.org 
[lkml]   [2008]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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]
\
 
 \ /
  Last update: 2008-06-24 07:53    [W:0.160 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site