[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <57A3F98D.1060500@zoho.com>
Date: Fri, 5 Aug 2016 10:27:25 +0800
From: zijun_hu <zijun_hu@...o.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: tj@...nel.org, hannes@...xchg.org, mhocko@...nel.org,
minchan@...nel.org, zijun_hu@....com, rientjes@...gle.com,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] mm/vmalloc: fix align value calculation error
On 08/05/2016 05:24 AM, Andrew Morton wrote:
>>
>> it causes double align requirement for __get_vm_area_node() if parameter
>> size is power of 2 and VM_IOREMAP is set in parameter flags
>>
>> it is fixed by handling the specail case manually due to lack of
>> get_count_order() for long parameter
>>
>> ...
>>
>> --- a/mm/vmalloc.c
>> +++ b/mm/vmalloc.c
>> @@ -1357,11 +1357,16 @@ static struct vm_struct *__get_vm_area_node(unsigned long size,
>> {
>> struct vmap_area *va;
>> struct vm_struct *area;
>> + int ioremap_size_order;
>>
>> BUG_ON(in_interrupt());
>> - if (flags & VM_IOREMAP)
>> - align = 1ul << clamp_t(int, fls_long(size),
>> - PAGE_SHIFT, IOREMAP_MAX_ORDER);
>> + if (flags & VM_IOREMAP) {
>> + ioremap_size_order = fls_long(size);
>> + if (is_power_of_2(size) && size != 1)
>> + ioremap_size_order--;
>> + align = 1ul << clamp_t(int, ioremap_size_order, PAGE_SHIFT,
>> + IOREMAP_MAX_ORDER);
>> + }
>>
>> size = PAGE_ALIGN(size);
>> if (unlikely(!size))
>
> I'm having trouble with this, and a more complete description would
> have helped!
>
> As far as I can tell, the current code will decide the following:
>
> size=0x10000: alignment=0x10000
> size=0x0f000: alignment=0x8000
>
no, the current code doesn't achieve the above results as shown below
size=0x10000 -> fls_long(0x10000)=17 -> alignment=0x20000
size=0x0f000 -> fls_long(0x0f000)=16 -> alignment=0x10000
it is wrong for power of 2 value such as size=0x10000
> And your patch will change it so that
>
> size=0x10000: alignment=0x8000
> size=0x0f000: alignment=0x8000
>
> Correct?
>
no, my patch will results in the following calculations
size=0x10000: alignment=0x10000
size=0x0f000: alignment=0x10000
> If so, I'm struggling to see the sense in this. Shouldn't we be
> changing things so that
>
> size=0x10000: alignment=0x10000
> size=0x0f000: alignment=0x10000
>
> ?
okay, it is the aim of my patch as explained above
>
>
Powered by blists - more mailing lists