From: "Dave Young" <hidave.darkstar@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, hpa@zytor.com,
the arch/x86 maintainers <x86@kernel.org>,
Yinghai Lu <yhlu.kernel@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] kernel parameter vmalloc size fix
Date: Fri, 11 Jul 2008 15:05:27 +0800 [thread overview]
Message-ID: <a8e1da0807110005h25ceeeabybeb2ad96e1abbb8e@mail.gmail.com> (raw)
In-Reply-To: <a8e1da0806261855l172a1e55k8bad10aa62e92521@mail.gmail.com>
On Fri, Jun 27, 2008 at 9:55 AM, Dave Young <hidave.darkstar@gmail.com> wrote:
> On Thu, Jun 26, 2008 at 8:14 PM, Ingo Molnar <mingo@elte.hu> wrote:
>>
>> * Dave Young <hidave.darkstar@gmail.com> wrote:
>>
>>> 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.
>>
>> i've ported it to tip/master, see the patch below. Yinghai, what do you
>> think about this change?
What's the status of this? It's indeed a bug which can be easily reproduced.
Anyone care about it?
Is it necessary for me to send it again for review?
(Add andrew in cc, maybe it could be put into mm to test)
>
> Thanks. If there's no objections please add my signed-off line
>
> Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
>
>>
>> Ingo
>>
>> ---
>> arch/x86/mm/pgtable_32.c | 3 ++-
>> include/asm-x86/page_32.h | 1 -
>> include/asm-x86/pgtable_32.h | 5 +++--
>> 3 files changed, 5 insertions(+), 4 deletions(-)
>>
>> Index: tip/arch/x86/mm/pgtable_32.c
>> ===================================================================
>> --- tip.orig/arch/x86/mm/pgtable_32.c
>> +++ tip/arch/x86/mm/pgtable_32.c
>> @@ -171,7 +171,8 @@ static int __init parse_vmalloc(char *ar
>> if (!arg)
>> return -EINVAL;
>>
>> - __VMALLOC_RESERVE = memparse(arg, &arg);
>> + /* Add VMALLOC_OFFSET to the parsed value due to vm area guard hole*/
>> + __VMALLOC_RESERVE = memparse(arg, &arg) + VMALLOC_OFFSET;
>> return 0;
>> }
>> early_param("vmalloc", parse_vmalloc);
>> Index: tip/include/asm-x86/page_32.h
>> ===================================================================
>> --- tip.orig/include/asm-x86/page_32.h
>> +++ tip/include/asm-x86/page_32.h
>> @@ -95,7 +95,6 @@ extern unsigned int __VMALLOC_RESERVE;
>> extern int sysctl_legacy_va_layout;
>>
>> #define VMALLOC_RESERVE ((unsigned long)__VMALLOC_RESERVE)
>> -#define MAXMEM (-__PAGE_OFFSET - __VMALLOC_RESERVE)
>>
>> extern void find_low_pfn_range(void);
>> extern unsigned long init_memory_mapping(unsigned long start,
>> Index: tip/include/asm-x86/pgtable_32.h
>> ===================================================================
>> --- tip.orig/include/asm-x86/pgtable_32.h
>> +++ tip/include/asm-x86/pgtable_32.h
>> @@ -56,8 +56,7 @@ void paging_init(void);
>> * area for the same reason. ;)
>> */
>> #define VMALLOC_OFFSET (8 * 1024 * 1024)
>> -#define VMALLOC_START (((unsigned long)high_memory + 2 * VMALLOC_OFFSET - 1) \
>> - & ~(VMALLOC_OFFSET - 1))
>> +#define VMALLOC_START ((unsigned long)high_memory + VMALLOC_OFFSET)
>> #ifdef CONFIG_X86_PAE
>> #define LAST_PKMAP 512
>> #else
>> @@ -73,6 +72,8 @@ void paging_init(void);
>> # define VMALLOC_END (FIXADDR_START - 2 * PAGE_SIZE)
>> #endif
>>
>> +#define MAXMEM (VMALLOC_END - PAGE_OFFSET - __VMALLOC_RESERVE)
>> +
>> /*
>> * Define this if things work differently on an i386 and an i486:
>> * it will (on an i486) warn about kernel memory accesses that are
>>
>>
>
>
>
> --
> Regards
> dave
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2008-07-11 7:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-16 4:25 Dave Young
2008-06-16 8:01 ` Ingo Molnar
2008-06-16 8:08 ` Dave Young
2008-06-16 8:52 ` Dave Young
2008-06-16 15:44 ` H. Peter Anvin
2008-06-24 5:49 ` Dave Young
2008-06-26 12:14 ` Ingo Molnar
2008-06-27 1:55 ` Dave Young
2008-07-11 7:05 ` Dave Young [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a8e1da0807110005h25ceeeabybeb2ad96e1abbb8e@mail.gmail.com \
--to=hidave.darkstar@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=x86@kernel.org \
--cc=yhlu.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox