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