mm: fix faulty initialization in vmalloc_init()

[KyongHo Cho <pullip.cho@samsung.com>]

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

On Fri, May 25, 2012 at 9:24 AM, Olav Haugan <ohaugan@codeaurora.org> wrote:
>> -----Original Message-----
>> On Thu, 24 May 2012 17:32:56 +0900
>> KyongHo <pullip.cho@samsung.com> wrote:
>>
>> > --- a/mm/vmalloc.c
>> > +++ b/mm/vmalloc.c
>> > @@ -1185,9 +1185,10 @@ void __init vmalloc_init(void)
>> >     /* Import existing vmlist entries. */
>> >     for (tmp = vmlist; tmp; tmp = tmp->next) {
>> >             va = kzalloc(sizeof(struct vmap_area), GFP_NOWAIT);
>  > -            va->flags = tmp->flags | VM_VM_AREA;
>> > +           va->flags = VM_VM_AREA;
>>
>> This change is a mystery.  Why do we no longer transfer ->flags?
>
> I was actually debugging the same exact issue today. This transfer of
flags
> actually causes some of the static mapping virtual addresses to be
> prematurely freed (before the mapping is removed) because VM_LAZY_FREE
gets
> "set" if tmp->flags has VM_IOREMAP set. This might cause subsequent
> vmalloc/ioremap calls to fail because it might allocate one of the freed
> virtual address ranges that aren't unmapped.
>
Thanks for description.

va->flags has different types of flags from tmp->flags.
If a region with VM_IOREMAP set is registered with vm_area_add_early(),
it will be removed by __purge_vmap_area_lazy().

 Cho KyongHo.

[-- Attachment #2: Type: text/html, Size: 1645 bytes --]