[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A1BBE51.8090208@redhat.com>
Date: Tue, 26 May 2009 18:02:57 +0800
From: Amerigo Wang <amwang@...hat.com>
To: Christoph Hellwig <hch@...radead.org>
CC: linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
rusty@...tcorp.com.au, jdike@...toit.com, mingo@...e.hu
Subject: Re: [Patch 2/4] x86 module: merge the rest functions with macros
Christoph Hellwig wrote:
> On Tue, May 26, 2009 at 04:35:22AM -0400, Amerigo Wang wrote:
>
>> +#if defined(CONFIG_UML) || defined(CONFIG_X86_32)
>> +void *module_alloc(unsigned long size)
>> +{
>> + if (size == 0)
>> + return NULL;
>> + return vmalloc_exec(size);
>> +}
>> +#else /*X86_64*/
>> +void *module_alloc(unsigned long size)
>> +{
>> + struct vm_struct *area;
>> +
>> + if (!size)
>> + return NULL;
>> + size = PAGE_ALIGN(size);
>> + if (size > MODULES_LEN)
>> + return NULL;
>> +
>> + area = __get_vm_area(size, VM_ALLOC, MODULES_VADDR, MODULES_END);
>> + if (!area)
>> + return NULL;
>> +
>> + return __vmalloc_area(area, GFP_KERNEL, PAGE_KERNEL_EXEC);
>> +}
>> +#endif
>>
>
> vmalloc_exec basically expands to the x86-64 version of that code, just
> using VMALLOC_START/VMALLOC_END instead of MODULES_VADDR/MODULES_END.
>
> So instead of having two variants it would be better to use the x86-64
> unconditionally and define MODULES_VADDR/MODULES_END to
> VMALLOC_START/VMALLOC_END to 32bit and uml.
>
> And that part should be a patch of it's own, not mixed with others.
>
Thanks, it is a good idea!
But... vmalloc_exec() also sets __GFP_HIGHMEM, this is different from
x86_64.
No? Or __GFP_HIGHMEM is meaningless on x86_64? :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists