Re: [PATCH] mm: fix oom roll-back of __vmalloc_area_node

[Jan Kiszka]

Andrew Morton wrote:

> On Tue, 11 Jul 2006 21:37:08 +0200
> Jan Kiszka <jan.kiszka@xxxxxx> wrote:
>
>   
>> __vunmap must not rely on area->nr_pages when picking the
>> release methode for area->pages. It may be too small when
>> __vmalloc_area_node failed early due to lacking memory.
>> Instead, use a flag in vmstruct to differentiate.
>>     
>
> So you mean that when this:
>
> 		if (unlikely(!area->pages[i])) {
> 			/* Successfully allocated i pages, free them in __vunmap() */
> 			area->nr_pages = i;
> 			goto fail;
>
> happens, it could be that i <= PAGE_SIZE/sizeof(struct page *) and __vunmap
> kfree()s something which it should have vfree()d, yes?
>
>   

Yes, exactly. It then causes some BUG in kfree during unroll.


> That sounds like a dead box, or worse.
>
>   
Someone triggered a too large vmalloc request, that was the scenario here.

> I think the change would be a good one even if it didn't fix a bug, thanks.
>
>   
Meanwhile I thought about an even simpler solution:


__vunmap must not rely on area->nr_pages when picking the
release methode for area->pages. It may be too small when
__vmalloc_area_node failed due to lacking memory. Check
for the vmalloc address range instead.

Signed-off by: Jan Kiszka <jan.kiszka@xxxxxx>

Index: linux-2.6/mm/vmalloc.c
===================================================================
--- linux-2.6.orig/mm/vmalloc.c
+++ linux-2.6/mm/vmalloc.c
@@ -340,7 +340,7 @@ void __vunmap(void *addr, int deallocate
 			__free_page(area->pages[i]);
 		}
 
-		if (area->nr_pages > PAGE_SIZE/sizeof(struct page *))
+		if (area->pages >= VMALLOC_START && area->pages < VMALLOC_END)
 			vfree(area->pages);
 		else
 			kfree(area->pages);


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/