linux-kernel - Re: [PATCH 1/2] Add vzalloc shortcut

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTi=t2U5wa_7pqcb1pAq6p_x7VqYKbfMDZ10q+Geq@mail.gmail.com>
Date:	Tue, 19 Oct 2010 09:55:17 +0800
From:	Dave Young <hidave.darkstar@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	kvm@...r.kernel.org
Subject: Re: [PATCH 1/2] Add vzalloc shortcut

On Tue, Oct 19, 2010 at 9:27 AM, Dave Young <hidave.darkstar@...il.com> wrote:
> On Tue, Oct 19, 2010 at 7:46 AM, Andrew Morton
> <akpm@...ux-foundation.org> wrote:
>> On Sat, 16 Oct 2010 12:33:31 +0800
>> Dave Young <hidave.darkstar@...il.com> wrote:
>>
>>> Add vzalloc for convinience of vmalloc-then-memset-zero case
>>>
>>> Use __GFP_ZERO in vzalloc to zero fill the allocated memory.
>>>
>>> Signed-off-by: Dave Young <hidave.darkstar@...il.com>
>>> ---
>>>  include/linux/vmalloc.h |    1 +
>>>  mm/vmalloc.c            |   13 +++++++++++++
>>>  2 files changed, 14 insertions(+)
>>>
>>> --- linux-2.6.orig/include/linux/vmalloc.h    2010-08-22 15:31:38.000000000 +0800
>>> +++ linux-2.6/include/linux/vmalloc.h 2010-10-16 10:50:54.739996121 +0800
>>> @@ -53,6 +53,7 @@ static inline void vmalloc_init(void)
>>>  #endif
>>>
>>>  extern void *vmalloc(unsigned long size);
>>> +extern void *vzalloc(unsigned long size);
>>>  extern void *vmalloc_user(unsigned long size);
>>>  extern void *vmalloc_node(unsigned long size, int node);
>>>  extern void *vmalloc_exec(unsigned long size);
>>> --- linux-2.6.orig/mm/vmalloc.c       2010-08-22 15:31:39.000000000 +0800
>>> +++ linux-2.6/mm/vmalloc.c    2010-10-16 10:51:57.126665918 +0800
>>> @@ -1604,6 +1604,19 @@ void *vmalloc(unsigned long size)
>>>  EXPORT_SYMBOL(vmalloc);
>>>
>>>  /**
>>> + *   vzalloc  -  allocate virtually contiguous memory with zero filled
>>
>> s/filled/fill/
>
> Thanks, Will fix
>
>>
>>> + *   @size:          allocation size
>>> + *   Allocate enough pages to cover @size from the page level
>>> + *   allocator and map them into contiguous kernel virtual space.
>>> + */
>>> +void *vzalloc(unsigned long size)
>>> +{
>>> +     return __vmalloc_node(size, 1, GFP_KERNEL | __GFP_HIGHMEM | __GFP_ZERO,
>>> +                             PAGE_KERNEL, -1, __builtin_return_address(0));
>>> +}
>>> +EXPORT_SYMBOL(vzalloc);
>>
>> We'd need to add the same interface to nommu, please.
>
> Ok, will do
>
> Minchan kim, thanks as well. I missed your comments about nommu before.
>
>>
>> Also, a slightly better implementation would be
>>
>> static inline void *__vmalloc_node_flags(unsigned long size, gfp_t flags)
>> {
>>        return __vmalloc_node(size, 1, flags, PAGE_KERNEL, -1,
>>                                __builtin_return_address(0));
>> }

Is this better? might __vmalloc_node_flags would be used by other than vmalloc?

static inline void *__vmalloc_node_flags(unsigned long size, int node,
gfp_t flags)

>>
>> void *vzalloc(unsigned long size)
>> {
>>        return __vmalloc_node_flags(size,
>>                                GFP_KERNEL | __GFP_HIGHMEM | __GFP_ZERO);
>> }
>>
>> void *vmalloc(unsigned long size)
>> {
>>        return __vmalloc_node_flags(size, GFP_KERNEL | __GFP_HIGHMEM);
>> }
>>
>> just to avoid code duplication (and possible later errors derived from it).
>>
>> Perhaps it should be always_inline, so the __builtin_return_address()
>> can't get broken.
>>
>> Or just leave it the way you had it :)
>
> Andrew, your suggestion is cleaner and better. I will do as yours.
>
> --
> Regards
> dave
>



-- 
Regards
dave
--
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/