mm: fix faulty initialization in vmalloc_init()

mm: fix faulty initialization in vmalloc_init()

[KyongHo]

vmalloc_init() adds 'vmap_area's for early 'vm_struct's.
This patch fixes vmalloc_init() to correctly initialize
vmap_area for the given vm_struct.

Signed-off-by: KyongHo Cho <pullip.cho@samsung.com>
---
 mm/vmalloc.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 94dff88..1196c77 100644
--- 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;
 		va->va_start = (unsigned long)tmp->addr;
 		va->va_end = va->va_start + tmp->size;
+		va->vm = tmp;
 		__insert_vmap_area(va);
 	}
 
-- 
1.7.1


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: mm: fix faulty initialization in vmalloc_init()

[Andrew Morton]

On Thu, 24 May 2012 17:32:56 +0900
KyongHo <pullip.cho@samsung.com> wrote:

> vmalloc_init() adds 'vmap_area's for early 'vm_struct's.
> This patch fixes vmalloc_init() to correctly initialize
> vmap_area for the given vm_struct.
> 

<daily message>
Insufficient information.  When fixing a bug please always always
always describe the user-visible effects of the bug.  Does the kernel
instantly crash?  Is it a comestic cleanliness thing which has no
effect?  Something in between?  I have simply no idea, and am dependent
upon you to tell me.

> --- 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?

>  		va->va_start = (unsigned long)tmp->addr;
>  		va->va_end = va->va_start + tmp->size;
> +		va->vm = tmp;

OK, I can see how this might be important.  But why did you find it
necessary?  Why was this change actually needed?

>  		__insert_vmap_area(va);
>  	}

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

RE: mm: fix faulty initialization in vmalloc_init()

[Olav Haugan]

> -----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. 

--
Olav Haugan

Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

mm: fix faulty initialization in vmalloc_init()

[KyongHo Cho]

[-- 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 --]

mm: fix faulty initialization in vmalloc_init()

[KyongHo Cho]

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

On Fri, May 25, 2012 at 7:12 AM, Andrew Morton <akpm@linux-foundation.org>
wrote:
> On Thu, 24 May 2012 17:32:56 +0900
> KyongHo <pullip.cho@samsung.com> wrote:
>
>> vmalloc_init() adds 'vmap_area's for early 'vm_struct's.
>> This patch fixes vmalloc_init() to correctly initialize
>> vmap_area for the given vm_struct.
>>
>
> <daily message>
> Insufficient information.  When fixing a bug please always always
> always describe the user-visible effects of the bug.  Does the kernel
> instantly crash?  Is it a comestic cleanliness thing which has no
> effect?  Something in between?  I have simply no idea, and am dependent
> upon you to tell me.

Sorry for unkind commit message :)
Why this patch is needed is described by Olav
in the previous replies.

>
>> --- 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?
>
>>               va->va_start = (unsigned long)tmp->addr;
>>               va->va_end = va->va_start + tmp->size;
>> +             va->vm = tmp;
>
> OK, I can see how this might be important.  But why did you find it
> necessary?  Why was this change actually needed?

If it is not set, find_vm_area() with the early vm regions will always fail.

If the early vm regions must be neither found by find_vm_area()
nor removed by remove_vm_area(), va->vm must be NULL.

Please advise me what is right value for va->vm here :)

>
>>               __insert_vmap_area(va);
>>       }
>
> --
> To unsubscribe from this list: send the line "unsubscribe
linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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