[PATCH] regression: vmalloc easily fail.

LKML Archive on lore.kernel.org
help / color / mirror / Atom feed

* [PATCH] regression: vmalloc easily fail.
@ 2008-10-28 22:55 Glauber Costa
  2008-10-28 21:03 ` Avi Kivity
  2008-10-28 23:29 ` Nick Piggin
  0 siblings, 2 replies; 24+ messages in thread
From: Glauber Costa @ 2008-10-28 22:55 UTC (permalink / raw)
  To: linux-kernel
  Cc: kvm, avi, aliguori, npiggin, Jeremy Fitzhardinge, Krzysztof Helt

Commit db64fe02258f1507e13fe5212a989922323685ce broke
KVM (the symptom) for me. The cause is that vmalloc
allocations fail, despite of the fact that /proc/meminfo
shows plenty of vmalloc space available.

After some investigation, it seems to me that the current
way to compute the next addr in the rb-tree transversal
leaves a spare page between each allocation. After a few
allocations, regardless of their size, we run out of vmalloc
space.

Signed-off-by: Glauber Costa <glommer@redhat.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
---
 mm/vmalloc.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 0365369..a33b0d1 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -363,7 +363,7 @@ retry:
 		}

 		while (addr + size >= first->va_start && addr + size <= vend) {
-			addr = ALIGN(first->va_end + PAGE_SIZE, align);
+			addr = ALIGN(first->va_end, align);

 			n = rb_next(&first->rb_node);
 			if (n)
-- 
1.5.6.5

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-28 22:55 [PATCH] regression: vmalloc easily fail Glauber Costa
@ 2008-10-28 21:03 ` Avi Kivity
  2008-10-28 21:09   ` Glauber Costa
  2008-10-28 21:22   ` Roland Dreier
  2008-10-28 23:29 ` Nick Piggin
  1 sibling, 2 replies; 24+ messages in thread
From: Avi Kivity @ 2008-10-28 21:03 UTC (permalink / raw)
  To: Glauber Costa
  Cc: linux-kernel, kvm, aliguori, npiggin, Jeremy Fitzhardinge,
	Krzysztof Helt

Glauber Costa wrote:
> Commit db64fe02258f1507e13fe5212a989922323685ce broke
> KVM (the symptom) for me. The cause is that vmalloc
> allocations fail, despite of the fact that /proc/meminfo
> shows plenty of vmalloc space available.
>
> After some investigation, it seems to me that the current
> way to compute the next addr in the rb-tree transversal
> leaves a spare page between each allocation. After a few
> allocations, regardless of their size, we run out of vmalloc
> space.
>
>  
>  		while (addr + size >= first->va_start && addr + size <= vend) {
> -			addr = ALIGN(first->va_end + PAGE_SIZE, align);
> +			addr = ALIGN(first->va_end, align);
>  
>  			n = rb_next(&first->rb_node);
>  			if (n)
>   

I'm guessing that the missing comment explains that this is intentional, 
to trap buffer overflows?

(okay that was a cheap shot.  I don't comment nearly enough either)

Even if you leave a page between allocations, I don't see how you can 
fail a one page allocation, unless you've allocated at least N/2 pages 
(where N is the size of the vmalloc space in pages).

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-28 21:03 ` Avi Kivity
@ 2008-10-28 21:09   ` Glauber Costa
  2008-10-28 21:22     ` Matias Zabaljauregui
  2008-10-28 21:22   ` Roland Dreier
  1 sibling, 1 reply; 24+ messages in thread
From: Glauber Costa @ 2008-10-28 21:09 UTC (permalink / raw)
  To: Avi Kivity
  Cc: linux-kernel, kvm, aliguori, npiggin, Jeremy Fitzhardinge,
	Krzysztof Helt

On Tue, Oct 28, 2008 at 11:03:22PM +0200, Avi Kivity wrote:
> Glauber Costa wrote:
>> Commit db64fe02258f1507e13fe5212a989922323685ce broke
>> KVM (the symptom) for me. The cause is that vmalloc
>> allocations fail, despite of the fact that /proc/meminfo
>> shows plenty of vmalloc space available.
>>
>> After some investigation, it seems to me that the current
>> way to compute the next addr in the rb-tree transversal
>> leaves a spare page between each allocation. After a few
>> allocations, regardless of their size, we run out of vmalloc
>> space.
>>
>>   		while (addr + size >= first->va_start && addr + size <= vend) {
>> -			addr = ALIGN(first->va_end + PAGE_SIZE, align);
>> +			addr = ALIGN(first->va_end, align);
>>   			n = rb_next(&first->rb_node);
>>  			if (n)
>>   
>
> I'm guessing that the missing comment explains that this is intentional,  
> to trap buffer overflows?
>
> (okay that was a cheap shot.  I don't comment nearly enough either)
>
> Even if you leave a page between allocations, I don't see how you can  
> fail a one page allocation, unless you've allocated at least N/2 pages  
> (where N is the size of the vmalloc space in pages).

I'm hoping Nick will comment on it. I might well be wrong.
but it nicely fixes the problem for me, and actually, you don't need 
"at least N/2 pages". The size of the allocations hardly matters, just
the amount of allocations we did. Since kvm does some small
vmalloc allocations, that may be the reason for we triggering it.



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-28 21:09   ` Glauber Costa
@ 2008-10-28 21:22     ` Matias Zabaljauregui
  0 siblings, 0 replies; 24+ messages in thread
From: Matias Zabaljauregui @ 2008-10-28 21:22 UTC (permalink / raw)
  To: Glauber Costa
  Cc: Avi Kivity, linux-kernel, kvm, aliguori, npiggin,
	Jeremy Fitzhardinge, Krzysztof Helt

hello,

>> I'm guessing that the missing comment explains that this is intentional,
>> to trap buffer overflows?

yes, IIRC the pages between vmalloc areas are there for safety reasons.
(like the interval inserted before the first area, defined by VMALLOC_OFFSET)

regards
Matias

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-28 21:03 ` Avi Kivity
  2008-10-28 21:09   ` Glauber Costa
@ 2008-10-28 21:22   ` Roland Dreier
  2008-10-28 21:42     ` Arjan van de Ven
  1 sibling, 1 reply; 24+ messages in thread
From: Roland Dreier @ 2008-10-28 21:22 UTC (permalink / raw)
  To: Avi Kivity
  Cc: Glauber Costa, linux-kernel, kvm, aliguori, npiggin,
	Jeremy Fitzhardinge, Krzysztof Helt

 > I'm guessing that the missing comment explains that this is
 > intentional, to trap buffer overflows?

Actually, speaking of comments, it's interesting that
__get_vm_area_node() -- which is called from vmalloc() -- does:

	/*
	 * We always allocate a guard page.
	 */
	size += PAGE_SIZE;

	va = alloc_vmap_area(size, align, start, end, node, gfp_mask);

and alloc_vmap_area() adds another PAGE_SIZE, as the original email
pointed out:

		while (addr + size >= first->va_start && addr + size <= vend) {
			addr = ALIGN(first->va_end + PAGE_SIZE, align);

I wonder if the double padding is causing a problem when things get too
fragmented?

 - R.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-28 21:22   ` Roland Dreier
@ 2008-10-28 21:42     ` Arjan van de Ven
  2008-10-28 22:03       ` Roland Dreier
  0 siblings, 1 reply; 24+ messages in thread
From: Arjan van de Ven @ 2008-10-28 21:42 UTC (permalink / raw)
  To: Roland Dreier
  Cc: Avi Kivity, Glauber Costa, linux-kernel, kvm, aliguori, npiggin,
	Jeremy Fitzhardinge, Krzysztof Helt

On Tue, 28 Oct 2008 14:22:16 -0700
Roland Dreier <rdreier@cisco.com> wrote:

>  > I'm guessing that the missing comment explains that this is
>  > intentional, to trap buffer overflows?
> 
> Actually, speaking of comments, it's interesting that
> __get_vm_area_node() -- which is called from vmalloc() -- does:
> 
> 	/*
> 	 * We always allocate a guard page.
> 	 */
> 	size += PAGE_SIZE;
> 
> 	va = alloc_vmap_area(size, align, start, end, node, gfp_mask);
> 
> and alloc_vmap_area() adds another PAGE_SIZE, as the original email
> pointed out:
> 
> 		while (addr + size >= first->va_start && addr + size
> <= vend) { addr = ALIGN(first->va_end + PAGE_SIZE, align);
> 
> I wonder if the double padding is causing a problem when things get
> too fragmented?

I suspect it's a case of off-by-one... ALIGN() might round down, and
the "+ (PAGE_SIZE-1)" was there to make it round up.
Except for that missing -1 ...

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-28 21:42     ` Arjan van de Ven
@ 2008-10-28 22:03       ` Roland Dreier
  0 siblings, 0 replies; 24+ messages in thread
From: Roland Dreier @ 2008-10-28 22:03 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: Avi Kivity, Glauber Costa, linux-kernel, kvm, aliguori, npiggin,
	Jeremy Fitzhardinge, Krzysztof Helt

 > I suspect it's a case of off-by-one... ALIGN() might round down, and
 > the "+ (PAGE_SIZE-1)" was there to make it round up.
 > Except for that missing -1 ...

ALIGN() has always rounded up, at least back to 2.4.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-28 22:55 [PATCH] regression: vmalloc easily fail Glauber Costa
  2008-10-28 21:03 ` Avi Kivity
@ 2008-10-28 23:29 ` Nick Piggin
  2008-10-29  6:28   ` Avi Kivity
  2008-10-29  9:48   ` Glauber Costa
  1 sibling, 2 replies; 24+ messages in thread
From: Nick Piggin @ 2008-10-28 23:29 UTC (permalink / raw)
  To: Glauber Costa
  Cc: linux-kernel, kvm, avi, aliguori, Jeremy Fitzhardinge, Krzysztof Helt

On Tue, Oct 28, 2008 at 08:55:13PM -0200, Glauber Costa wrote:
> Commit db64fe02258f1507e13fe5212a989922323685ce broke
> KVM (the symptom) for me. The cause is that vmalloc
> allocations fail, despite of the fact that /proc/meminfo
> shows plenty of vmalloc space available.
> 
> After some investigation, it seems to me that the current
> way to compute the next addr in the rb-tree transversal
> leaves a spare page between each allocation. After a few
> allocations, regardless of their size, we run out of vmalloc
> space.

Right... that was to add a guard page like the old vmalloc allocator.
vmallocs still add their extra page too, so most of them will have
a 2 page guard area, but I didn't think this would hurt significantly.

I'm not against the patch, but I wonder exactly what is filling it up
and how? (can you look at the vmalloc proc function to find out?)

> 
> Signed-off-by: Glauber Costa <glommer@redhat.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
> ---
>  mm/vmalloc.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 0365369..a33b0d1 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -363,7 +363,7 @@ retry:
>  		}
>  
>  		while (addr + size >= first->va_start && addr + size <= vend) {
> -			addr = ALIGN(first->va_end + PAGE_SIZE, align);
> +			addr = ALIGN(first->va_end, align);
>  
>  			n = rb_next(&first->rb_node);
>  			if (n)
> -- 
> 1.5.6.5

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-28 23:29 ` Nick Piggin
@ 2008-10-29  6:28   ` Avi Kivity
  2008-10-29  9:48   ` Glauber Costa
  1 sibling, 0 replies; 24+ messages in thread
From: Avi Kivity @ 2008-10-29  6:28 UTC (permalink / raw)
  To: Nick Piggin
  Cc: Glauber Costa, linux-kernel, kvm, aliguori, Jeremy Fitzhardinge,
	Krzysztof Helt

Nick Piggin wrote:
> Right... that was to add a guard page like the old vmalloc allocator.
> vmallocs still add their extra page too, so most of them will have
> a 2 page guard area, but I didn't think this would hurt significantly.
>
> I'm not against the patch, but I wonder exactly what is filling it up
> and how? (can you look at the vmalloc proc function to find out?

Maybe we're allocating two guard pages, but freeing only one?

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-28 23:29 ` Nick Piggin
  2008-10-29  6:28   ` Avi Kivity
@ 2008-10-29  9:48   ` Glauber Costa
  2008-10-29 10:11     ` Nick Piggin
  1 sibling, 1 reply; 24+ messages in thread
From: Glauber Costa @ 2008-10-29  9:48 UTC (permalink / raw)
  To: Nick Piggin
  Cc: linux-kernel, kvm, avi, aliguori, Jeremy Fitzhardinge, Krzysztof Helt

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

On Wed, Oct 29, 2008 at 12:29:44AM +0100, Nick Piggin wrote:
> On Tue, Oct 28, 2008 at 08:55:13PM -0200, Glauber Costa wrote:
> > Commit db64fe02258f1507e13fe5212a989922323685ce broke
> > KVM (the symptom) for me. The cause is that vmalloc
> > allocations fail, despite of the fact that /proc/meminfo
> > shows plenty of vmalloc space available.
> > 
> > After some investigation, it seems to me that the current
> > way to compute the next addr in the rb-tree transversal
> > leaves a spare page between each allocation. After a few
> > allocations, regardless of their size, we run out of vmalloc
> > space.
> 
> Right... that was to add a guard page like the old vmalloc allocator.
> vmallocs still add their extra page too, so most of them will have
> a 2 page guard area, but I didn't think this would hurt significantly.
> 
> I'm not against the patch, but I wonder exactly what is filling it up
> and how? (can you look at the vmalloc proc function to find out?)
attached.

> 
> > 
> > Signed-off-by: Glauber Costa <glommer@redhat.com>
> > Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> > Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
> > ---
> >  mm/vmalloc.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index 0365369..a33b0d1 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -363,7 +363,7 @@ retry:
> >  		}
> >  
> >  		while (addr + size >= first->va_start && addr + size <= vend) {
> > -			addr = ALIGN(first->va_end + PAGE_SIZE, align);
> > +			addr = ALIGN(first->va_end, align);
> >  
> >  			n = rb_next(&first->rb_node);
> >  			if (n)
> > -- 
> > 1.5.6.5

[-- Attachment #2: vmalloc-fails --]
[-- Type: text/plain, Size: 10720 bytes --]

0xf7bfe000-0xf7c00000    8192 hpet_enable+0x2d/0x279 phys=fed00000 ioremap
0xf7c02000-0xf7c04000    8192 acpi_os_map_memory+0x11/0x1a phys=7fed1000 ioremap
0xf7c06000-0xf7c08000    8192 acpi_os_map_memory+0x11/0x1a phys=7fef2000 ioremap
0xf7c0a000-0xf7c0c000    8192 acpi_os_map_memory+0x11/0x1a phys=7fef2000 ioremap
0xf7c0d000-0xf7c0f000    8192 __kvm_set_memory_region+0x164/0x355 [kvm] pages=1 vmalloc
0xf7c10000-0xf7c1f000   61440 acpi_os_map_memory+0x11/0x1a phys=7fed1000 ioremap
0xf7c20000-0xf7c22000    8192 acpi_os_map_memory+0x11/0x1a phys=7fef2000 ioremap
0xf7c24000-0xf7c27000   12288 acpi_os_map_memory+0x11/0x1a phys=7fef2000 ioremap
0xf7c28000-0xf7c2a000    8192 acpi_os_map_memory+0x11/0x1a phys=7fede000 ioremap
0xf7c2c000-0xf7c2e000    8192 acpi_os_map_memory+0x11/0x1a phys=7fef4000 ioremap
0xf7c30000-0xf7c32000    8192 acpi_os_map_memory+0x11/0x1a phys=7fede000 ioremap
0xf7c34000-0xf7c36000    8192 acpi_os_map_memory+0x11/0x1a phys=7fef4000 ioremap
0xf7c38000-0xf7c3a000    8192 acpi_os_map_memory+0x11/0x1a phys=7fed1000 ioremap
0xf7c3c000-0xf7c3e000    8192 acpi_os_map_memory+0x11/0x1a phys=7fede000 ioremap
0xf7c40000-0xf7c42000    8192 acpi_os_map_memory+0x11/0x1a phys=7fede000 ioremap
0xf7c44000-0xf7c46000    8192 acpi_os_map_memory+0x11/0x1a phys=7fede000 ioremap
0xf7c48000-0xf7c4a000    8192 acpi_os_map_memory+0x11/0x1a phys=7fede000 ioremap
0xf7c4b000-0xf7c57000   49152 zisofs_init+0xd/0x1c pages=11 vmalloc
0xf7c58000-0xf7c5a000    8192 yenta_probe+0x123/0x63f phys=e4300000 ioremap
0xf7c5b000-0xf7c5e000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
0xf7c61000-0xf7c65000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
0xf7c67000-0xf7c71000   40960 vmalloc_exec+0x12/0x14 pages=9 vmalloc
0xf7c72000-0xf7c74000    8192 usb_hcd_pci_probe+0x132/0x277 phys=ee404000 ioremap
0xf7c75000-0xf7c7c000   28672 vmalloc_exec+0x12/0x14 pages=6 vmalloc
0xf7c7d000-0xf7c86000   36864 vmalloc_exec+0x12/0x14 pages=8 vmalloc
0xf7c87000-0xf7c89000    8192 __kvm_set_memory_region+0x1df/0x355 [kvm] pages=1 vmalloc
0xf7c8a000-0xf7c91000   28672 vmalloc_exec+0x12/0x14 pages=6 vmalloc
0xf7c92000-0xf7c97000   20480 vmalloc_exec+0x12/0x14 pages=4 vmalloc
0xf7c9b000-0xf7c9f000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
0xf7ca0000-0xf7ca5000   20480 vmalloc_exec+0x12/0x14 pages=4 vmalloc
0xf7ca6000-0xf7cab000   20480 vmalloc_exec+0x12/0x14 pages=4 vmalloc
0xf7cac000-0xf7caf000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
0xf7cb0000-0xf7cb2000    8192 iTCO_wdt_probe+0xbe/0x281 [iTCO_wdt] phys=fed1f000 ioremap
0xf7cb3000-0xf7cbf000   49152 vmalloc_exec+0x12/0x14 pages=11 vmalloc
0xf7cc0000-0xf7cce000   57344 vmalloc_exec+0x12/0x14 pages=13 vmalloc
0xf7ccf000-0xf7cd2000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
0xf7cd3000-0xf7cd5000    8192 __kvm_set_memory_region+0x164/0x355 [kvm] pages=1 vmalloc
0xf7cd6000-0xf7cdc000   24576 vmalloc_exec+0x12/0x14 pages=5 vmalloc
0xf7cdd000-0xf7ce0000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
0xf7ce1000-0xf7ce4000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
0xf7ce6000-0xf7d02000  114688 vmalloc_exec+0x12/0x14 pages=27 vmalloc
0xf7d03000-0xf7d08000   20480 vmalloc_exec+0x12/0x14 pages=4 vmalloc
0xf7d09000-0xf7d0b000    8192 __kvm_set_memory_region+0x1df/0x355 [kvm] pages=1 vmalloc
0xf7d0c000-0xf7d12000   24576 vmalloc_exec+0x12/0x14 pages=5 vmalloc
0xf7d13000-0xf7d24000   69632 snd_malloc_sgbuf_pages+0x190/0x1ca [snd_page_alloc] vmap
0xf7d25000-0xf7d2a000   20480 drm_ht_create+0x69/0xa5 [drm] pages=4 vmalloc
0xf7d2d000-0xf7d2f000    8192 dm_vcalloc+0x24/0x4c [dm_mod] pages=1 vmalloc
0xf7d30000-0xf7d50000  131072 vmalloc_exec+0x12/0x14 pages=31 vmalloc
0xf7d51000-0xf7d54000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
0xf7d56000-0xf7d5a000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
0xf7d5b000-0xf7d5e000   12288 vmalloc_user+0x13/0x38 pages=2 vmalloc user
0xf7d5f000-0xf7d67000   32768 vmalloc_exec+0x12/0x14 pages=7 vmalloc
0xf7d68000-0xf7d79000   69632 snd_malloc_sgbuf_pages+0x190/0x1ca [snd_page_alloc] vmap
0xf7d7a000-0xf7d86000   49152 vmalloc_exec+0x12/0x14 pages=11 vmalloc
0xf7d87000-0xf7d8e000   28672 vmalloc_exec+0x12/0x14 pages=6 vmalloc
0xf7d8f000-0xf7d91000    8192 __kvm_set_memory_region+0x164/0x355 [kvm] pages=1 vmalloc
0xf7d92000-0xf7d94000    8192 dm_vcalloc+0x24/0x4c [dm_mod] pages=1 vmalloc
0xf7d96000-0xf7dba000  147456 vmalloc_exec+0x12/0x14 pages=35 vmalloc
0xf7dbb000-0xf7dc0000   20480 vmalloc_exec+0x12/0x14 pages=4 vmalloc
0xf7dc1000-0xf7dc4000   12288 vmalloc_32+0x12/0x14 pages=2 vmalloc
0xf7dc7000-0xf7dc9000    8192 dm_vcalloc+0x24/0x4c [dm_mod] pages=1 vmalloc
0xf7dcb000-0xf7dd4000   36864 vmalloc_exec+0x12/0x14 pages=8 vmalloc
0xf7dd5000-0xf7dd7000    8192 __kvm_set_memory_region+0x1df/0x355 [kvm] pages=1 vmalloc
0xf7dd8000-0xf7dda000    8192 pci_iomap+0x72/0x7b phys=ee404000 ioremap
0xf7ddb000-0xf7dec000   69632 snd_malloc_sgbuf_pages+0x190/0x1ca [snd_page_alloc] vmap
0xf7ded000-0xf7e0e000  135168 vmalloc_exec+0x12/0x14 pages=32 vmalloc
0xf7e0f000-0xf7e23000   81920 vmalloc_exec+0x12/0x14 pages=19 vmalloc
0xf7e24000-0xf7e2a000   24576 vmalloc_exec+0x12/0x14 pages=5 vmalloc
0xf7e2b000-0xf7e2f000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
0xf7e30000-0xf7e34000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
0xf7e36000-0xf7e45000   61440 vmalloc_exec+0x12/0x14 pages=14 vmalloc
0xf7e46000-0xf7e68000  139264 vmalloc_exec+0x12/0x14 pages=33 vmalloc
0xf7e6d000-0xf7e6f000    8192 __kvm_set_memory_region+0x164/0x355 [kvm] pages=1 vmalloc
0xf7e70000-0xf7e79000   36864 ioremap_wc+0x21/0x23 phys=dbff8000 ioremap
0xf7e80000-0xf7e91000   69632 drm_addmap_core+0x16d/0x4d5 [drm] phys=ee100000 ioremap
0xf7e92000-0xf7ea0000   57344 vmalloc_exec+0x12/0x14 pages=13 vmalloc
0xf7ea1000-0xf7ea6000   20480 vmalloc_exec+0x12/0x14 pages=4 vmalloc
0xf7ec8000-0xf7ecf000   28672 vmalloc_exec+0x12/0x14 pages=6 vmalloc
0xf7ed0000-0xf7f06000  221184 vmalloc_exec+0x12/0x14 pages=53 vmalloc
0xf7f07000-0xf7f0e000   28672 vmalloc_exec+0x12/0x14 pages=6 vmalloc
0xf7f0f000-0xf7f28000  102400 vmalloc_exec+0x12/0x14 pages=24 vmalloc
0xf7f29000-0xf7f2f000   24576 vmalloc_exec+0x12/0x14 pages=5 vmalloc
0xf7f3c000-0xf7f3e000    8192 __kvm_set_memory_region+0x1df/0x355 [kvm] pages=1 vmalloc
0xf7f3f000-0xf7f42000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
0xf7f43000-0xf7f4d000   40960 vmalloc_exec+0x12/0x14 pages=9 vmalloc
0xf7f4e000-0xf7f50000    8192 __kvm_set_memory_region+0x164/0x355 [kvm] pages=1 vmalloc
0xf7f51000-0xf7f57000   24576 vmalloc_exec+0x12/0x14 pages=5 vmalloc
0xf7f59000-0xf7f67000   57344 vmalloc_exec+0x12/0x14 pages=13 vmalloc
0xf7faa000-0xf7fbc000   73728 vmalloc_exec+0x12/0x14 pages=17 vmalloc
0xf802f000-0xf8032000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
0xf8033000-0xf8039000   24576 vmalloc_exec+0x12/0x14 pages=5 vmalloc
0xf803a000-0xf803c000    8192 __kvm_set_memory_region+0x1df/0x355 [kvm] pages=1 vmalloc
0xf803d000-0xf8043000   24576 vmalloc_exec+0x12/0x14 pages=5 vmalloc
0xf8044000-0xf8046000    8192 __kvm_set_memory_region+0x164/0x355 [kvm] pages=1 vmalloc
0xf8047000-0xf8053000   49152 vmalloc_exec+0x12/0x14 pages=11 vmalloc
0xf8054000-0xf8058000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
0xf8059000-0xf805b000    8192 __kvm_set_memory_region+0x1df/0x355 [kvm] pages=1 vmalloc
0xf805c000-0xf805e000    8192 pci_iomap+0x72/0x7b phys=edf00000 ioremap
0xf8062000-0xf8066000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
0xf8069000-0xf806b000    8192 dm_vcalloc+0x24/0x4c [dm_mod] pages=1 vmalloc
0xf80c0000-0xf81b9000 1019904 sys_swapon+0x481/0xaa0 pages=248 vmalloc
0xf81e3000-0xf81e8000   20480 vmalloc_exec+0x12/0x14 pages=4 vmalloc
0xf8237000-0xf823c000   20480 vmalloc_exec+0x12/0x14 pages=4 vmalloc
0xf8275000-0xf827a000   20480 vmalloc_exec+0x12/0x14 pages=4 vmalloc
0xf8451000-0xf845f000   57344 vmalloc_exec+0x12/0x14 pages=13 vmalloc
0xf848a000-0xf848d000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
0xf84ba000-0xf84bd000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
0xf84be000-0xf84c2000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
0xf84f1000-0xf84f4000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
0xf84f5000-0xf84f8000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
0xf8502000-0xf8510000   57344 vmalloc_exec+0x12/0x14 pages=13 vmalloc
0xf8511000-0xf851f000   57344 vmalloc_exec+0x12/0x14 pages=13 vmalloc
0xf8523000-0xf852a000   28672 vmalloc_exec+0x12/0x14 pages=6 vmalloc
0xf8534000-0xf8538000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
0xf8539000-0xf853b000    8192 __kvm_set_memory_region+0x1df/0x355 [kvm] pages=1 vmalloc
0xf853c000-0xf8545000   36864 vmalloc_exec+0x12/0x14 pages=8 vmalloc
0xf8546000-0xf8550000   40960 vmalloc_exec+0x12/0x14 pages=9 vmalloc
0xf8551000-0xf8554000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
0xf8555000-0xf8561000   49152 vmalloc_exec+0x12/0x14 pages=11 vmalloc
0xf856c000-0xf856f000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
0xf8578000-0xf857d000   20480 azx_probe+0x32b/0xa0a [snd_hda_intel] phys=ee400000 ioremap
0xf8594000-0xf85c1000  184320 vmalloc_exec+0x12/0x14 pages=44 vmalloc
0xf85db000-0xf85df000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
0xf85f4000-0xf85f6000    8192 __kvm_set_memory_region+0x255/0x355 [kvm] pages=1 vmalloc
0xf85f7000-0xf85fa000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
0xf85fb000-0xf8620000  151552 vmalloc_exec+0x12/0x14 pages=36 vmalloc
0xf8624000-0xf8628000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
0xf8629000-0xf8689000  393216 vmalloc_exec+0x12/0x14 pages=95 vmalloc
0xf868a000-0xf8690000   24576 vmalloc_exec+0x12/0x14 pages=5 vmalloc
0xf8691000-0xf8695000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
0xf8699000-0xf869c000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
0xf86a5000-0xf86a9000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
0xf86c4000-0xf86c7000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
0xf87a6000-0xf87af000   36864 vmalloc_exec+0x12/0x14 pages=8 vmalloc
0xf87dd000-0xf87e2000   20480 vmalloc_exec+0x12/0x14 pages=4 vmalloc
0xf8815000-0xf881c000   28672 vmalloc_exec+0x12/0x14 pages=6 vmalloc
0xf89b8000-0xf89d2000  106496 vmalloc_exec+0x12/0x14 pages=25 vmalloc
0xf8a00000-0xf8a21000  135168 e1000_probe+0x1a5/0xbb3 [e1000e] phys=ee000000 ioremap
0xf8a22000-0xf9223000 8392704 vmalloc_32+0x12/0x14 pages=2048 vmalloc vpages
0xf97a4000-0xf97a7000   12288 e1000e_setup_tx_resources+0x1d/0xbf [e1000e] pages=2 vmalloc
0xf97a8000-0xf97ab000   12288 e1000e_setup_rx_resources+0x1d/0xfa [e1000e] pages=2 vmalloc
0xf97ac000-0xf98ad000 1052672 __kvm_set_memory_region+0x164/0x355 [kvm] pages=256 vmalloc
0xf98ae000-0xf98b1000   12288 __kvm_set_memory_region+0x1df/0x355 [kvm] pages=2 vmalloc
0xf98b2000-0xf98b7000   20480 __kvm_set_memory_region+0x164/0x355 [kvm] pages=4 vmalloc

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-29  9:48   ` Glauber Costa
@ 2008-10-29 10:11     ` Nick Piggin
  2008-10-29 10:29       ` Avi Kivity
  0 siblings, 1 reply; 24+ messages in thread
From: Nick Piggin @ 2008-10-29 10:11 UTC (permalink / raw)
  To: Glauber Costa
  Cc: linux-kernel, kvm, avi, aliguori, Jeremy Fitzhardinge, Krzysztof Helt

On Wed, Oct 29, 2008 at 07:48:56AM -0200, Glauber Costa wrote:

> 0xf7bfe000-0xf7c00000    8192 hpet_enable+0x2d/0x279 phys=fed00000 ioremap
> 0xf7c02000-0xf7c04000    8192 acpi_os_map_memory+0x11/0x1a phys=7fed1000 ioremap
> 0xf7c06000-0xf7c08000    8192 acpi_os_map_memory+0x11/0x1a phys=7fef2000 ioremap
> 0xf7c0a000-0xf7c0c000    8192 acpi_os_map_memory+0x11/0x1a phys=7fef2000 ioremap
> 0xf7c0d000-0xf7c0f000    8192 __kvm_set_memory_region+0x164/0x355 [kvm] pages=1 vmalloc
> 0xf7c10000-0xf7c1f000   61440 acpi_os_map_memory+0x11/0x1a phys=7fed1000 ioremap
> 0xf7c20000-0xf7c22000    8192 acpi_os_map_memory+0x11/0x1a phys=7fef2000 ioremap
> 0xf7c24000-0xf7c27000   12288 acpi_os_map_memory+0x11/0x1a phys=7fef2000 ioremap
> 0xf7c28000-0xf7c2a000    8192 acpi_os_map_memory+0x11/0x1a phys=7fede000 ioremap
> 0xf7c2c000-0xf7c2e000    8192 acpi_os_map_memory+0x11/0x1a phys=7fef4000 ioremap
> 0xf7c30000-0xf7c32000    8192 acpi_os_map_memory+0x11/0x1a phys=7fede000 ioremap
> 0xf7c34000-0xf7c36000    8192 acpi_os_map_memory+0x11/0x1a phys=7fef4000 ioremap
> 0xf7c38000-0xf7c3a000    8192 acpi_os_map_memory+0x11/0x1a phys=7fed1000 ioremap
> 0xf7c3c000-0xf7c3e000    8192 acpi_os_map_memory+0x11/0x1a phys=7fede000 ioremap
> 0xf7c40000-0xf7c42000    8192 acpi_os_map_memory+0x11/0x1a phys=7fede000 ioremap
> 0xf7c44000-0xf7c46000    8192 acpi_os_map_memory+0x11/0x1a phys=7fede000 ioremap
> 0xf7c48000-0xf7c4a000    8192 acpi_os_map_memory+0x11/0x1a phys=7fede000 ioremap
> 0xf7c4b000-0xf7c57000   49152 zisofs_init+0xd/0x1c pages=11 vmalloc
> 0xf7c58000-0xf7c5a000    8192 yenta_probe+0x123/0x63f phys=e4300000 ioremap
> 0xf7c5b000-0xf7c5e000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
> 0xf7c61000-0xf7c65000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
> 0xf7c67000-0xf7c71000   40960 vmalloc_exec+0x12/0x14 pages=9 vmalloc
> 0xf7c72000-0xf7c74000    8192 usb_hcd_pci_probe+0x132/0x277 phys=ee404000 ioremap
> 0xf7c75000-0xf7c7c000   28672 vmalloc_exec+0x12/0x14 pages=6 vmalloc
> 0xf7c7d000-0xf7c86000   36864 vmalloc_exec+0x12/0x14 pages=8 vmalloc
> 0xf7c87000-0xf7c89000    8192 __kvm_set_memory_region+0x1df/0x355 [kvm] pages=1 vmalloc
> 0xf7c8a000-0xf7c91000   28672 vmalloc_exec+0x12/0x14 pages=6 vmalloc
> 0xf7c92000-0xf7c97000   20480 vmalloc_exec+0x12/0x14 pages=4 vmalloc
> 0xf7c9b000-0xf7c9f000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
> 0xf7ca0000-0xf7ca5000   20480 vmalloc_exec+0x12/0x14 pages=4 vmalloc
> 0xf7ca6000-0xf7cab000   20480 vmalloc_exec+0x12/0x14 pages=4 vmalloc
> 0xf7cac000-0xf7caf000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
> 0xf7cb0000-0xf7cb2000    8192 iTCO_wdt_probe+0xbe/0x281 [iTCO_wdt] phys=fed1f000 ioremap
> 0xf7cb3000-0xf7cbf000   49152 vmalloc_exec+0x12/0x14 pages=11 vmalloc
> 0xf7cc0000-0xf7cce000   57344 vmalloc_exec+0x12/0x14 pages=13 vmalloc
> 0xf7ccf000-0xf7cd2000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
> 0xf7cd3000-0xf7cd5000    8192 __kvm_set_memory_region+0x164/0x355 [kvm] pages=1 vmalloc
> 0xf7cd6000-0xf7cdc000   24576 vmalloc_exec+0x12/0x14 pages=5 vmalloc
> 0xf7cdd000-0xf7ce0000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
> 0xf7ce1000-0xf7ce4000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
> 0xf7ce6000-0xf7d02000  114688 vmalloc_exec+0x12/0x14 pages=27 vmalloc
> 0xf7d03000-0xf7d08000   20480 vmalloc_exec+0x12/0x14 pages=4 vmalloc
> 0xf7d09000-0xf7d0b000    8192 __kvm_set_memory_region+0x1df/0x355 [kvm] pages=1 vmalloc
> 0xf7d0c000-0xf7d12000   24576 vmalloc_exec+0x12/0x14 pages=5 vmalloc
> 0xf7d13000-0xf7d24000   69632 snd_malloc_sgbuf_pages+0x190/0x1ca [snd_page_alloc] vmap
> 0xf7d25000-0xf7d2a000   20480 drm_ht_create+0x69/0xa5 [drm] pages=4 vmalloc
> 0xf7d2d000-0xf7d2f000    8192 dm_vcalloc+0x24/0x4c [dm_mod] pages=1 vmalloc
> 0xf7d30000-0xf7d50000  131072 vmalloc_exec+0x12/0x14 pages=31 vmalloc
> 0xf7d51000-0xf7d54000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
> 0xf7d56000-0xf7d5a000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
> 0xf7d5b000-0xf7d5e000   12288 vmalloc_user+0x13/0x38 pages=2 vmalloc user
> 0xf7d5f000-0xf7d67000   32768 vmalloc_exec+0x12/0x14 pages=7 vmalloc
> 0xf7d68000-0xf7d79000   69632 snd_malloc_sgbuf_pages+0x190/0x1ca [snd_page_alloc] vmap
> 0xf7d7a000-0xf7d86000   49152 vmalloc_exec+0x12/0x14 pages=11 vmalloc
> 0xf7d87000-0xf7d8e000   28672 vmalloc_exec+0x12/0x14 pages=6 vmalloc
> 0xf7d8f000-0xf7d91000    8192 __kvm_set_memory_region+0x164/0x355 [kvm] pages=1 vmalloc
> 0xf7d92000-0xf7d94000    8192 dm_vcalloc+0x24/0x4c [dm_mod] pages=1 vmalloc
> 0xf7d96000-0xf7dba000  147456 vmalloc_exec+0x12/0x14 pages=35 vmalloc
> 0xf7dbb000-0xf7dc0000   20480 vmalloc_exec+0x12/0x14 pages=4 vmalloc
> 0xf7dc1000-0xf7dc4000   12288 vmalloc_32+0x12/0x14 pages=2 vmalloc
> 0xf7dc7000-0xf7dc9000    8192 dm_vcalloc+0x24/0x4c [dm_mod] pages=1 vmalloc
> 0xf7dcb000-0xf7dd4000   36864 vmalloc_exec+0x12/0x14 pages=8 vmalloc
> 0xf7dd5000-0xf7dd7000    8192 __kvm_set_memory_region+0x1df/0x355 [kvm] pages=1 vmalloc
> 0xf7dd8000-0xf7dda000    8192 pci_iomap+0x72/0x7b phys=ee404000 ioremap
> 0xf7ddb000-0xf7dec000   69632 snd_malloc_sgbuf_pages+0x190/0x1ca [snd_page_alloc] vmap
> 0xf7ded000-0xf7e0e000  135168 vmalloc_exec+0x12/0x14 pages=32 vmalloc
> 0xf7e0f000-0xf7e23000   81920 vmalloc_exec+0x12/0x14 pages=19 vmalloc
> 0xf7e24000-0xf7e2a000   24576 vmalloc_exec+0x12/0x14 pages=5 vmalloc
> 0xf7e2b000-0xf7e2f000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
> 0xf7e30000-0xf7e34000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
> 0xf7e36000-0xf7e45000   61440 vmalloc_exec+0x12/0x14 pages=14 vmalloc
> 0xf7e46000-0xf7e68000  139264 vmalloc_exec+0x12/0x14 pages=33 vmalloc
> 0xf7e6d000-0xf7e6f000    8192 __kvm_set_memory_region+0x164/0x355 [kvm] pages=1 vmalloc
> 0xf7e70000-0xf7e79000   36864 ioremap_wc+0x21/0x23 phys=dbff8000 ioremap
> 0xf7e80000-0xf7e91000   69632 drm_addmap_core+0x16d/0x4d5 [drm] phys=ee100000 ioremap
> 0xf7e92000-0xf7ea0000   57344 vmalloc_exec+0x12/0x14 pages=13 vmalloc
> 0xf7ea1000-0xf7ea6000   20480 vmalloc_exec+0x12/0x14 pages=4 vmalloc
> 0xf7ec8000-0xf7ecf000   28672 vmalloc_exec+0x12/0x14 pages=6 vmalloc
> 0xf7ed0000-0xf7f06000  221184 vmalloc_exec+0x12/0x14 pages=53 vmalloc
> 0xf7f07000-0xf7f0e000   28672 vmalloc_exec+0x12/0x14 pages=6 vmalloc
> 0xf7f0f000-0xf7f28000  102400 vmalloc_exec+0x12/0x14 pages=24 vmalloc
> 0xf7f29000-0xf7f2f000   24576 vmalloc_exec+0x12/0x14 pages=5 vmalloc
> 0xf7f3c000-0xf7f3e000    8192 __kvm_set_memory_region+0x1df/0x355 [kvm] pages=1 vmalloc
> 0xf7f3f000-0xf7f42000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
> 0xf7f43000-0xf7f4d000   40960 vmalloc_exec+0x12/0x14 pages=9 vmalloc
> 0xf7f4e000-0xf7f50000    8192 __kvm_set_memory_region+0x164/0x355 [kvm] pages=1 vmalloc
> 0xf7f51000-0xf7f57000   24576 vmalloc_exec+0x12/0x14 pages=5 vmalloc
> 0xf7f59000-0xf7f67000   57344 vmalloc_exec+0x12/0x14 pages=13 vmalloc
> 0xf7faa000-0xf7fbc000   73728 vmalloc_exec+0x12/0x14 pages=17 vmalloc
> 0xf802f000-0xf8032000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
> 0xf8033000-0xf8039000   24576 vmalloc_exec+0x12/0x14 pages=5 vmalloc
> 0xf803a000-0xf803c000    8192 __kvm_set_memory_region+0x1df/0x355 [kvm] pages=1 vmalloc
> 0xf803d000-0xf8043000   24576 vmalloc_exec+0x12/0x14 pages=5 vmalloc
> 0xf8044000-0xf8046000    8192 __kvm_set_memory_region+0x164/0x355 [kvm] pages=1 vmalloc
> 0xf8047000-0xf8053000   49152 vmalloc_exec+0x12/0x14 pages=11 vmalloc
> 0xf8054000-0xf8058000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
> 0xf8059000-0xf805b000    8192 __kvm_set_memory_region+0x1df/0x355 [kvm] pages=1 vmalloc
> 0xf805c000-0xf805e000    8192 pci_iomap+0x72/0x7b phys=edf00000 ioremap
> 0xf8062000-0xf8066000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
> 0xf8069000-0xf806b000    8192 dm_vcalloc+0x24/0x4c [dm_mod] pages=1 vmalloc
> 0xf80c0000-0xf81b9000 1019904 sys_swapon+0x481/0xaa0 pages=248 vmalloc
> 0xf81e3000-0xf81e8000   20480 vmalloc_exec+0x12/0x14 pages=4 vmalloc
> 0xf8237000-0xf823c000   20480 vmalloc_exec+0x12/0x14 pages=4 vmalloc
> 0xf8275000-0xf827a000   20480 vmalloc_exec+0x12/0x14 pages=4 vmalloc
> 0xf8451000-0xf845f000   57344 vmalloc_exec+0x12/0x14 pages=13 vmalloc
> 0xf848a000-0xf848d000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
> 0xf84ba000-0xf84bd000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
> 0xf84be000-0xf84c2000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
> 0xf84f1000-0xf84f4000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
> 0xf84f5000-0xf84f8000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
> 0xf8502000-0xf8510000   57344 vmalloc_exec+0x12/0x14 pages=13 vmalloc
> 0xf8511000-0xf851f000   57344 vmalloc_exec+0x12/0x14 pages=13 vmalloc
> 0xf8523000-0xf852a000   28672 vmalloc_exec+0x12/0x14 pages=6 vmalloc
> 0xf8534000-0xf8538000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
> 0xf8539000-0xf853b000    8192 __kvm_set_memory_region+0x1df/0x355 [kvm] pages=1 vmalloc
> 0xf853c000-0xf8545000   36864 vmalloc_exec+0x12/0x14 pages=8 vmalloc
> 0xf8546000-0xf8550000   40960 vmalloc_exec+0x12/0x14 pages=9 vmalloc
> 0xf8551000-0xf8554000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
> 0xf8555000-0xf8561000   49152 vmalloc_exec+0x12/0x14 pages=11 vmalloc
> 0xf856c000-0xf856f000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
> 0xf8578000-0xf857d000   20480 azx_probe+0x32b/0xa0a [snd_hda_intel] phys=ee400000 ioremap
> 0xf8594000-0xf85c1000  184320 vmalloc_exec+0x12/0x14 pages=44 vmalloc
> 0xf85db000-0xf85df000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
> 0xf85f4000-0xf85f6000    8192 __kvm_set_memory_region+0x255/0x355 [kvm] pages=1 vmalloc
> 0xf85f7000-0xf85fa000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
> 0xf85fb000-0xf8620000  151552 vmalloc_exec+0x12/0x14 pages=36 vmalloc
> 0xf8624000-0xf8628000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
> 0xf8629000-0xf8689000  393216 vmalloc_exec+0x12/0x14 pages=95 vmalloc
> 0xf868a000-0xf8690000   24576 vmalloc_exec+0x12/0x14 pages=5 vmalloc
> 0xf8691000-0xf8695000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
> 0xf8699000-0xf869c000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
> 0xf86a5000-0xf86a9000   16384 vmalloc_exec+0x12/0x14 pages=3 vmalloc
> 0xf86c4000-0xf86c7000   12288 vmalloc_exec+0x12/0x14 pages=2 vmalloc
> 0xf87a6000-0xf87af000   36864 vmalloc_exec+0x12/0x14 pages=8 vmalloc
> 0xf87dd000-0xf87e2000   20480 vmalloc_exec+0x12/0x14 pages=4 vmalloc
> 0xf8815000-0xf881c000   28672 vmalloc_exec+0x12/0x14 pages=6 vmalloc
> 0xf89b8000-0xf89d2000  106496 vmalloc_exec+0x12/0x14 pages=25 vmalloc
> 0xf8a00000-0xf8a21000  135168 e1000_probe+0x1a5/0xbb3 [e1000e] phys=ee000000 ioremap
> 0xf8a22000-0xf9223000 8392704 vmalloc_32+0x12/0x14 pages=2048 vmalloc vpages
> 0xf97a4000-0xf97a7000   12288 e1000e_setup_tx_resources+0x1d/0xbf [e1000e] pages=2 vmalloc
> 0xf97a8000-0xf97ab000   12288 e1000e_setup_rx_resources+0x1d/0xfa [e1000e] pages=2 vmalloc
> 0xf97ac000-0xf98ad000 1052672 __kvm_set_memory_region+0x164/0x355 [kvm] pages=256 vmalloc
> 0xf98ae000-0xf98b1000   12288 __kvm_set_memory_region+0x1df/0x355 [kvm] pages=2 vmalloc
> 0xf98b2000-0xf98b7000   20480 __kvm_set_memory_region+0x164/0x355 [kvm] pages=4 vmalloc

Hmm, spanning <30MB of memory... how much vmalloc space do you have?

Anyway, there's quite a lot of little allocations there, and things are
getting a bit fragmented. Why don't we just drop the guard pages
completely (maybe turn them on with a debug option)? I don't think I have
ever seen a problem caught by them... not to say they can't catch problems,
but those problems could equally appear in linear KVA too (or between guard
pages).




^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-29 10:11     ` Nick Piggin
@ 2008-10-29 10:29       ` Avi Kivity
  2008-10-29 10:43         ` Nick Piggin
  0 siblings, 1 reply; 24+ messages in thread
From: Avi Kivity @ 2008-10-29 10:29 UTC (permalink / raw)
  To: Nick Piggin
  Cc: Glauber Costa, linux-kernel, kvm, aliguori, Jeremy Fitzhardinge,
	Krzysztof Helt

Nick Piggin wrote:
> Hmm, spanning <30MB of memory... how much vmalloc space do you have?
>
>   

 From the original report:

> VmallocTotal:     122880 kB
> VmallocUsed:       15184 kB
> VmallocChunk:      83764 kB

So it seems there's quite a bit of free space.

Chunk is the largest free contiguous region, right?  If so, it seems the 
problem is unrelated to guard pages, instead the search isn't finding a 
1-page area (with two guard pages) for some reason, even though lots of 
free space is available.


-- 
error compiling committee.c: too many arguments to function


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-29 10:29       ` Avi Kivity
@ 2008-10-29 10:43         ` Nick Piggin
  2008-10-29 22:07           ` Glauber Costa
  0 siblings, 1 reply; 24+ messages in thread
From: Nick Piggin @ 2008-10-29 10:43 UTC (permalink / raw)
  To: Avi Kivity
  Cc: Glauber Costa, linux-kernel, kvm, aliguori, Jeremy Fitzhardinge,
	Krzysztof Helt

On Wed, Oct 29, 2008 at 12:29:40PM +0200, Avi Kivity wrote:
> Nick Piggin wrote:
> >Hmm, spanning <30MB of memory... how much vmalloc space do you have?
> >
> >  
> 
> From the original report:
> 
> >VmallocTotal:     122880 kB
> >VmallocUsed:       15184 kB
> >VmallocChunk:      83764 kB
> 
> So it seems there's quite a bit of free space.
> 
> Chunk is the largest free contiguous region, right?  If so, it seems the 

Yes.


> problem is unrelated to guard pages, instead the search isn't finding a 
> 1-page area (with two guard pages) for some reason, even though lots of 
> free space is available.

Hmm. The free area search could be buggy...

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-29 10:43         ` Nick Piggin
@ 2008-10-29 22:07           ` Glauber Costa
  2008-10-30  1:53             ` Nick Piggin
  2008-10-30  4:49             ` Nick Piggin
  0 siblings, 2 replies; 24+ messages in thread
From: Glauber Costa @ 2008-10-29 22:07 UTC (permalink / raw)
  To: Nick Piggin
  Cc: Avi Kivity, linux-kernel, kvm, aliguori, Jeremy Fitzhardinge,
	Krzysztof Helt

On Wed, Oct 29, 2008 at 11:43:33AM +0100, Nick Piggin wrote:
> On Wed, Oct 29, 2008 at 12:29:40PM +0200, Avi Kivity wrote:
> > Nick Piggin wrote:
> > >Hmm, spanning <30MB of memory... how much vmalloc space do you have?
> > >
> > >  
> > 
> > From the original report:
> > 
> > >VmallocTotal:     122880 kB
> > >VmallocUsed:       15184 kB
> > >VmallocChunk:      83764 kB
> > 
> > So it seems there's quite a bit of free space.
> > 
> > Chunk is the largest free contiguous region, right?  If so, it seems the 
> 
> Yes.
> 
> 
> > problem is unrelated to guard pages, instead the search isn't finding a 
> > 1-page area (with two guard pages) for some reason, even though lots of 
> > free space is available.
> 
> Hmm. The free area search could be buggy...
Do you want me to grab any specific info of it? Or should I just hack myself
randomly into it? I'll probably have some time for that tomorrow.


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-29 22:07           ` Glauber Costa
@ 2008-10-30  1:53             ` Nick Piggin
  2008-10-30  4:49             ` Nick Piggin
  1 sibling, 0 replies; 24+ messages in thread
From: Nick Piggin @ 2008-10-30  1:53 UTC (permalink / raw)
  To: Glauber Costa
  Cc: Avi Kivity, linux-kernel, kvm, aliguori, Jeremy Fitzhardinge,
	Krzysztof Helt

On Wed, Oct 29, 2008 at 08:07:37PM -0200, Glauber Costa wrote:
> On Wed, Oct 29, 2008 at 11:43:33AM +0100, Nick Piggin wrote:
> > On Wed, Oct 29, 2008 at 12:29:40PM +0200, Avi Kivity wrote:
> > > Nick Piggin wrote:
> > > >Hmm, spanning <30MB of memory... how much vmalloc space do you have?
> > > >
> > > >  
> > > 
> > > From the original report:
> > > 
> > > >VmallocTotal:     122880 kB
> > > >VmallocUsed:       15184 kB
> > > >VmallocChunk:      83764 kB
> > > 
> > > So it seems there's quite a bit of free space.
> > > 
> > > Chunk is the largest free contiguous region, right?  If so, it seems the 
> > 
> > Yes.
> > 
> > 
> > > problem is unrelated to guard pages, instead the search isn't finding a 
> > > 1-page area (with two guard pages) for some reason, even though lots of 
> > > free space is available.
> > 
> > Hmm. The free area search could be buggy...
> Do you want me to grab any specific info of it? Or should I just hack myself
> randomly into it? I'll probably have some time for that tomorrow.

I can take a look at it, in the next day or two. If you hack at it, and
find the problem I wouldn't be upset ;)

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-29 22:07           ` Glauber Costa
  2008-10-30  1:53             ` Nick Piggin
@ 2008-10-30  4:49             ` Nick Piggin
  2008-10-30 11:28               ` Glauber Costa
                                 ` (2 more replies)
  1 sibling, 3 replies; 24+ messages in thread
From: Nick Piggin @ 2008-10-30  4:49 UTC (permalink / raw)
  To: Glauber Costa
  Cc: Avi Kivity, linux-kernel, kvm, aliguori, Jeremy Fitzhardinge,
	Krzysztof Helt

On Wed, Oct 29, 2008 at 08:07:37PM -0200, Glauber Costa wrote:
> On Wed, Oct 29, 2008 at 11:43:33AM +0100, Nick Piggin wrote:
> > On Wed, Oct 29, 2008 at 12:29:40PM +0200, Avi Kivity wrote:
> > > Nick Piggin wrote:
> > > >Hmm, spanning <30MB of memory... how much vmalloc space do you have?
> > > >
> > > >  
> > > 
> > > From the original report:
> > > 
> > > >VmallocTotal:     122880 kB
> > > >VmallocUsed:       15184 kB
> > > >VmallocChunk:      83764 kB
> > > 
> > > So it seems there's quite a bit of free space.
> > > 
> > > Chunk is the largest free contiguous region, right?  If so, it seems the 
> > 
> > Yes.
> > 
> > 
> > > problem is unrelated to guard pages, instead the search isn't finding a 
> > > 1-page area (with two guard pages) for some reason, even though lots of 
> > > free space is available.
> > 
> > Hmm. The free area search could be buggy...
> Do you want me to grab any specific info of it? Or should I just hack myself
> randomly into it? I'll probably have some time for that tomorrow.

I took a bit of a look. Does this help you at all?

I still think we should get rid of the guard pages in non-debug kernels
completely, but hopefully this will fix your problems?
--

- Fix off by one bug in the KVA allocator that can leave gaps 
- An initial vmalloc failure should start off a synchronous flush of lazy
  areas, in case someone is in progress flushing them already.
- Purge lock can be a mutex so we can sleep while that's going on.
 
Signed-off-by: Nick Piggin <npiggin@suse.de>
---
Index: linux-2.6/mm/vmalloc.c
===================================================================
--- linux-2.6.orig/mm/vmalloc.c
+++ linux-2.6/mm/vmalloc.c
@@ -14,6 +14,7 @@
 #include <linux/highmem.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
+#include <linux/mutex.h>
 #include <linux/interrupt.h>
 #include <linux/proc_fs.h>
 #include <linux/seq_file.h>
@@ -362,7 +363,7 @@ retry:
 				goto found;
 		}
 
-		while (addr + size >= first->va_start && addr + size <= vend) {
+		while (addr + size > first->va_start && addr + size <= vend) {
 			addr = ALIGN(first->va_end + PAGE_SIZE, align);
 
 			n = rb_next(&first->rb_node);
@@ -472,7 +473,7 @@ static atomic_t vmap_lazy_nr = ATOMIC_IN
 static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
 					int sync, int force_flush)
 {
-	static DEFINE_SPINLOCK(purge_lock);
+	static DEFINE_MUTEX(purge_lock);
 	LIST_HEAD(valist);
 	struct vmap_area *va;
 	int nr = 0;
@@ -483,10 +484,10 @@ static void __purge_vmap_area_lazy(unsig
 	 * the case that isn't actually used at the moment anyway.
 	 */
 	if (!sync && !force_flush) {
-		if (!spin_trylock(&purge_lock))
+		if (!mutex_trylock(&purge_lock))
 			return;
 	} else
-		spin_lock(&purge_lock);
+		mutex_lock(&purge_lock);
 
 	rcu_read_lock();
 	list_for_each_entry_rcu(va, &vmap_area_list, list) {
@@ -518,7 +519,18 @@ static void __purge_vmap_area_lazy(unsig
 			__free_vmap_area(va);
 		spin_unlock(&vmap_area_lock);
 	}
-	spin_unlock(&purge_lock);
+	mutex_unlock(&purge_lock);
+}
+
+/*
+ * Kick off a purge of the outstanding lazy areas. Don't bother if somebody
+ * is already purging.
+ */
+static void try_purge_vmap_area_lazy(void)
+{
+	unsigned long start = ULONG_MAX, end = 0;
+
+	__purge_vmap_area_lazy(&start, &end, 0, 0);
 }
 
 /*
@@ -528,7 +540,7 @@ static void purge_vmap_area_lazy(void)
 {
 	unsigned long start = ULONG_MAX, end = 0;
 
-	__purge_vmap_area_lazy(&start, &end, 0, 0);
+	__purge_vmap_area_lazy(&start, &end, 1, 0);
 }
 
 /*
@@ -539,7 +551,7 @@ static void free_unmap_vmap_area(struct 
 	va->flags |= VM_LAZY_FREE;
 	atomic_add((va->va_end - va->va_start) >> PAGE_SHIFT, &vmap_lazy_nr);
 	if (unlikely(atomic_read(&vmap_lazy_nr) > lazy_max_pages()))
-		purge_vmap_area_lazy();
+		try_purge_vmap_area_lazy();
 }
 
 static struct vmap_area *find_vmap_area(unsigned long addr)

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-30  4:49             ` Nick Piggin
@ 2008-10-30 11:28               ` Glauber Costa
  2008-10-31  7:16                 ` Nick Piggin
  2008-10-30 16:46               ` Matt Mackall
  2008-11-07 20:37               ` Glauber Costa
  2 siblings, 1 reply; 24+ messages in thread
From: Glauber Costa @ 2008-10-30 11:28 UTC (permalink / raw)
  To: Nick Piggin
  Cc: Avi Kivity, linux-kernel, kvm, aliguori, Jeremy Fitzhardinge,
	Krzysztof Helt

On Thu, Oct 30, 2008 at 05:49:41AM +0100, Nick Piggin wrote:
> On Wed, Oct 29, 2008 at 08:07:37PM -0200, Glauber Costa wrote:
> > On Wed, Oct 29, 2008 at 11:43:33AM +0100, Nick Piggin wrote:
> > > On Wed, Oct 29, 2008 at 12:29:40PM +0200, Avi Kivity wrote:
> > > > Nick Piggin wrote:
> > > > >Hmm, spanning <30MB of memory... how much vmalloc space do you have?
> > > > >
> > > > >  
> > > > 
> > > > From the original report:
> > > > 
> > > > >VmallocTotal:     122880 kB
> > > > >VmallocUsed:       15184 kB
> > > > >VmallocChunk:      83764 kB
> > > > 
> > > > So it seems there's quite a bit of free space.
> > > > 
> > > > Chunk is the largest free contiguous region, right?  If so, it seems the 
> > > 
> > > Yes.
> > > 
> > > 
> > > > problem is unrelated to guard pages, instead the search isn't finding a 
> > > > 1-page area (with two guard pages) for some reason, even though lots of 
> > > > free space is available.
> > > 
> > > Hmm. The free area search could be buggy...
> > Do you want me to grab any specific info of it? Or should I just hack myself
> > randomly into it? I'll probably have some time for that tomorrow.
> 
> I took a bit of a look. Does this help you at all?
> 
> I still think we should get rid of the guard pages in non-debug kernels
> completely, but hopefully this will fix your problems?
unfortunately, it doesn't.
problem still happen in a kernel with this patch.

> --
> 
> - Fix off by one bug in the KVA allocator that can leave gaps 
> - An initial vmalloc failure should start off a synchronous flush of lazy
>   areas, in case someone is in progress flushing them already.
> - Purge lock can be a mutex so we can sleep while that's going on.
>  
> Signed-off-by: Nick Piggin <npiggin@suse.de>
> ---
> Index: linux-2.6/mm/vmalloc.c
> ===================================================================
> --- linux-2.6.orig/mm/vmalloc.c
> +++ linux-2.6/mm/vmalloc.c
> @@ -14,6 +14,7 @@
>  #include <linux/highmem.h>
>  #include <linux/slab.h>
>  #include <linux/spinlock.h>
> +#include <linux/mutex.h>
>  #include <linux/interrupt.h>
>  #include <linux/proc_fs.h>
>  #include <linux/seq_file.h>
> @@ -362,7 +363,7 @@ retry:
>  				goto found;
>  		}
>  
> -		while (addr + size >= first->va_start && addr + size <= vend) {
> +		while (addr + size > first->va_start && addr + size <= vend) {
>  			addr = ALIGN(first->va_end + PAGE_SIZE, align);
>  
>  			n = rb_next(&first->rb_node);
> @@ -472,7 +473,7 @@ static atomic_t vmap_lazy_nr = ATOMIC_IN
>  static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
>  					int sync, int force_flush)
>  {
> -	static DEFINE_SPINLOCK(purge_lock);
> +	static DEFINE_MUTEX(purge_lock);
>  	LIST_HEAD(valist);
>  	struct vmap_area *va;
>  	int nr = 0;
> @@ -483,10 +484,10 @@ static void __purge_vmap_area_lazy(unsig
>  	 * the case that isn't actually used at the moment anyway.
>  	 */
>  	if (!sync && !force_flush) {
> -		if (!spin_trylock(&purge_lock))
> +		if (!mutex_trylock(&purge_lock))
>  			return;
>  	} else
> -		spin_lock(&purge_lock);
> +		mutex_lock(&purge_lock);
>  
>  	rcu_read_lock();
>  	list_for_each_entry_rcu(va, &vmap_area_list, list) {
> @@ -518,7 +519,18 @@ static void __purge_vmap_area_lazy(unsig
>  			__free_vmap_area(va);
>  		spin_unlock(&vmap_area_lock);
>  	}
> -	spin_unlock(&purge_lock);
> +	mutex_unlock(&purge_lock);
> +}
> +
> +/*
> + * Kick off a purge of the outstanding lazy areas. Don't bother if somebody
> + * is already purging.
> + */
> +static void try_purge_vmap_area_lazy(void)
> +{
> +	unsigned long start = ULONG_MAX, end = 0;
> +
> +	__purge_vmap_area_lazy(&start, &end, 0, 0);
>  }
>  
>  /*
> @@ -528,7 +540,7 @@ static void purge_vmap_area_lazy(void)
>  {
>  	unsigned long start = ULONG_MAX, end = 0;
>  
> -	__purge_vmap_area_lazy(&start, &end, 0, 0);
> +	__purge_vmap_area_lazy(&start, &end, 1, 0);
>  }
>  
>  /*
> @@ -539,7 +551,7 @@ static void free_unmap_vmap_area(struct 
>  	va->flags |= VM_LAZY_FREE;
>  	atomic_add((va->va_end - va->va_start) >> PAGE_SHIFT, &vmap_lazy_nr);
>  	if (unlikely(atomic_read(&vmap_lazy_nr) > lazy_max_pages()))
> -		purge_vmap_area_lazy();
> +		try_purge_vmap_area_lazy();
>  }
>  
>  static struct vmap_area *find_vmap_area(unsigned long addr)

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-30 11:28               ` Glauber Costa
@ 2008-10-31  7:16                 ` Nick Piggin
  2008-11-04 17:51                   ` Glauber Costa
  2008-11-05  0:21                   ` Glauber Costa
  0 siblings, 2 replies; 24+ messages in thread
From: Nick Piggin @ 2008-10-31  7:16 UTC (permalink / raw)
  To: Glauber Costa
  Cc: Avi Kivity, linux-kernel, kvm, aliguori, Jeremy Fitzhardinge,
	Krzysztof Helt

On Thu, Oct 30, 2008 at 09:28:54AM -0200, Glauber Costa wrote:
> On Thu, Oct 30, 2008 at 05:49:41AM +0100, Nick Piggin wrote:
> > On Wed, Oct 29, 2008 at 08:07:37PM -0200, Glauber Costa wrote:
> > > On Wed, Oct 29, 2008 at 11:43:33AM +0100, Nick Piggin wrote:
> > > > On Wed, Oct 29, 2008 at 12:29:40PM +0200, Avi Kivity wrote:
> > > > > Nick Piggin wrote:
> > > > > >Hmm, spanning <30MB of memory... how much vmalloc space do you have?
> > > > > >
> > > > > >  
> > > > > 
> > > > > From the original report:
> > > > > 
> > > > > >VmallocTotal:     122880 kB
> > > > > >VmallocUsed:       15184 kB
> > > > > >VmallocChunk:      83764 kB
> > > > > 
> > > > > So it seems there's quite a bit of free space.
> > > > > 
> > > > > Chunk is the largest free contiguous region, right?  If so, it seems the 
> > > > 
> > > > Yes.
> > > > 
> > > > 
> > > > > problem is unrelated to guard pages, instead the search isn't finding a 
> > > > > 1-page area (with two guard pages) for some reason, even though lots of 
> > > > > free space is available.
> > > > 
> > > > Hmm. The free area search could be buggy...
> > > Do you want me to grab any specific info of it? Or should I just hack myself
> > > randomly into it? I'll probably have some time for that tomorrow.
> > 
> > I took a bit of a look. Does this help you at all?
> > 
> > I still think we should get rid of the guard pages in non-debug kernels
> > completely, but hopefully this will fix your problems?
> unfortunately, it doesn't.
> problem still happen in a kernel with this patch.

That's weird. Any chance you could dump a list of all the vmap area start
and end adresses and their flags before returning failure?




^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-31  7:16                 ` Nick Piggin
@ 2008-11-04 17:51                   ` Glauber Costa
  2008-11-05  0:21                   ` Glauber Costa
  1 sibling, 0 replies; 24+ messages in thread
From: Glauber Costa @ 2008-11-04 17:51 UTC (permalink / raw)
  To: Nick Piggin
  Cc: Avi Kivity, linux-kernel, kvm, aliguori, Jeremy Fitzhardinge,
	Krzysztof Helt

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

On Fri, Oct 31, 2008 at 08:16:44AM +0100, Nick Piggin wrote:
> On Thu, Oct 30, 2008 at 09:28:54AM -0200, Glauber Costa wrote:
> > On Thu, Oct 30, 2008 at 05:49:41AM +0100, Nick Piggin wrote:
> > > On Wed, Oct 29, 2008 at 08:07:37PM -0200, Glauber Costa wrote:
> > > > On Wed, Oct 29, 2008 at 11:43:33AM +0100, Nick Piggin wrote:
> > > > > On Wed, Oct 29, 2008 at 12:29:40PM +0200, Avi Kivity wrote:
> > > > > > Nick Piggin wrote:
> > > > > > >Hmm, spanning <30MB of memory... how much vmalloc space do you have?
> > > > > > >
> > > > > > >  
> > > > > > 
> > > > > > From the original report:
> > > > > > 
> > > > > > >VmallocTotal:     122880 kB
> > > > > > >VmallocUsed:       15184 kB
> > > > > > >VmallocChunk:      83764 kB
> > > > > > 
> > > > > > So it seems there's quite a bit of free space.
> > > > > > 
> > > > > > Chunk is the largest free contiguous region, right?  If so, it seems the 
> > > > > 
> > > > > Yes.
> > > > > 
> > > > > 
> > > > > > problem is unrelated to guard pages, instead the search isn't finding a 
> > > > > > 1-page area (with two guard pages) for some reason, even though lots of 
> > > > > > free space is available.
> > > > > 
> > > > > Hmm. The free area search could be buggy...
> > > > Do you want me to grab any specific info of it? Or should I just hack myself
> > > > randomly into it? I'll probably have some time for that tomorrow.
> > > 
> > > I took a bit of a look. Does this help you at all?
> > > 
> > > I still think we should get rid of the guard pages in non-debug kernels
> > > completely, but hopefully this will fix your problems?
> > unfortunately, it doesn't.
> > problem still happen in a kernel with this patch.
> 
> That's weird. Any chance you could dump a list of all the vmap area start
> and end adresses and their flags before returning failure?

by the way, a slightly modified version of your patch, without this snippet:

@@ -362,7 +363,7 @@ retry:
                                goto found;
                }

-               while (addr + size >= first->va_start && addr + size <= vend) {
+               while (addr + size > first->va_start && addr + size <= vend) {
                        addr = ALIGN(first->va_end + PAGE_SIZE, align);

                        n = rb_next(&first->rb_node);


WFM nicely so far.

I'm attaching /proc/vmallocinfo during kvm execution


[-- Attachment #2: vmalloc.works --]
[-- Type: text/plain, Size: 11042 bytes --]

0xf8800000-0xf8802000    8192 hpet_enable+0x2f/0x26b phys=fed00000 ioremap
0xf8802000-0xf8804000    8192 acpi_os_map_memory+0x15/0x1e phys=7fed1000 ioremap
0xf8804000-0xf8806000    8192 acpi_os_map_memory+0x15/0x1e phys=7fef2000 ioremap
0xf8806000-0xf8808000    8192 acpi_os_map_memory+0x15/0x1e phys=7fef2000 ioremap
0xf8808000-0xf880a000    8192 acpi_os_map_memory+0x15/0x1e phys=7fef2000 ioremap
0xf880a000-0xf880c000    8192 acpi_os_map_memory+0x15/0x1e phys=7fede000 ioremap
0xf880c000-0xf880f000   12288 acpi_os_map_memory+0x15/0x1e phys=7fef2000 ioremap
0xf8810000-0xf881f000   61440 acpi_os_map_memory+0x15/0x1e phys=7fed1000 ioremap
0xf8820000-0xf8822000    8192 acpi_os_map_memory+0x15/0x1e phys=7fef4000 ioremap
0xf8822000-0xf8824000    8192 acpi_os_map_memory+0x15/0x1e phys=7fede000 ioremap
0xf8824000-0xf8826000    8192 acpi_os_map_memory+0x15/0x1e phys=7fef4000 ioremap
0xf8826000-0xf8828000    8192 acpi_os_map_memory+0x15/0x1e phys=7fed1000 ioremap
0xf8828000-0xf882a000    8192 acpi_os_map_memory+0x15/0x1e phys=7fede000 ioremap
0xf882a000-0xf882c000    8192 acpi_os_map_memory+0x15/0x1e phys=7fede000 ioremap
0xf882c000-0xf882e000    8192 acpi_os_map_memory+0x15/0x1e phys=7fede000 ioremap
0xf882e000-0xf8830000    8192 acpi_os_map_memory+0x15/0x1e phys=7fede000 ioremap
0xf8830000-0xf883c000   49152 zisofs_init+0xd/0x1c pages=11 vmalloc
0xf883c000-0xf883e000    8192 acpi_os_map_memory+0x15/0x1e phys=7fef1000 ioremap
0xf883e000-0xf8840000    8192 acpi_os_map_memory+0x15/0x1e phys=7fef1000 ioremap
0xf8840000-0xf8843000   12288 acpi_os_map_memory+0x15/0x1e phys=7fef1000 ioremap
0xf8844000-0xf8846000    8192 acpi_os_map_memory+0x15/0x1e phys=7fef1000 ioremap
0xf8846000-0xf8848000    8192 usb_hcd_pci_probe+0x168/0x30c phys=ee404000 ioremap
0xf8848000-0xf884a000    8192 dm_vcalloc+0x24/0x4c [dm_mod] pages=1 vmalloc
0xf884a000-0xf884c000    8192 pci_iomap+0xb6/0xc2 phys=ee404000 ioremap
0xf884d000-0xf8851000   16384 vmalloc_exec+0x13/0x15 pages=3 vmalloc
0xf8851000-0xf885b000   40960 vmalloc_exec+0x13/0x15 pages=9 vmalloc
0xf885b000-0xf8862000   28672 vmalloc_exec+0x13/0x15 pages=6 vmalloc
0xf8862000-0xf8869000   28672 vmalloc_exec+0x13/0x15 pages=6 vmalloc
0xf8869000-0xf8876000   53248 vmalloc_exec+0x13/0x15 pages=12 vmalloc
0xf8877000-0xf8882000   45056 vmalloc_exec+0x13/0x15 pages=10 vmalloc
0xf8882000-0xf88a1000  126976 vmalloc_exec+0x13/0x15 pages=30 vmalloc
0xf88a1000-0xf88a3000    8192 dm_vcalloc+0x24/0x4c [dm_mod] pages=1 vmalloc
0xf88a3000-0xf88bf000  114688 vmalloc_exec+0x13/0x15 pages=27 vmalloc
0xf88bf000-0xf88c7000   32768 vmalloc_exec+0x13/0x15 pages=7 vmalloc
0xf88c7000-0xf88cf000   32768 vmalloc_exec+0x13/0x15 pages=7 vmalloc
0xf88cf000-0xf88d1000    8192 __kvm_set_memory_region+0x155/0x304 [kvm] pages=1 vmalloc
0xf88d1000-0xf88d4000   12288 vmalloc_exec+0x13/0x15 pages=2 vmalloc
0xf88d4000-0xf88d8000   16384 vmalloc_exec+0x13/0x15 pages=3 vmalloc
0xf88d8000-0xf88db000   12288 vmalloc_exec+0x13/0x15 pages=2 vmalloc
0xf88db000-0xf88dd000    8192 dm_vcalloc+0x24/0x4c [dm_mod] pages=1 vmalloc
0xf88dd000-0xf88df000    8192 dm_vcalloc+0x24/0x4c [dm_mod] pages=1 vmalloc
0xf88df000-0xf88e5000   24576 vmalloc_exec+0x13/0x15 pages=5 vmalloc
0xf88e5000-0xf88ee000   36864 vmalloc_exec+0x13/0x15 pages=8 vmalloc
0xf88ef000-0xf8911000  139264 vmalloc_exec+0x13/0x15 pages=33 vmalloc
0xf8911000-0xf8917000   24576 vmalloc_exec+0x13/0x15 pages=5 vmalloc
0xf8918000-0xf891a000    8192 iTCO_wdt_probe+0xb6/0x281 [iTCO_wdt] phys=fed1f000 ioremap
0xf891b000-0xf891f000   16384 vmalloc_exec+0x13/0x15 pages=3 vmalloc
0xf8920000-0xf8928000   32768 vmalloc_exec+0x13/0x15 pages=7 vmalloc
0xf8928000-0xf892b000   12288 vmalloc_exec+0x13/0x15 pages=2 vmalloc
0xf892b000-0xf892e000   12288 vmalloc_exec+0x13/0x15 pages=2 vmalloc
0xf892e000-0xf8931000   12288 vmalloc_exec+0x13/0x15 pages=2 vmalloc
0xf8932000-0xf894a000   98304 vmalloc_exec+0x13/0x15 pages=23 vmalloc
0xf894a000-0xf894d000   12288 vmalloc_exec+0x13/0x15 pages=2 vmalloc
0xf894d000-0xf8952000   20480 vmalloc_exec+0x13/0x15 pages=4 vmalloc
0xf8952000-0xf8959000   28672 vmalloc_exec+0x13/0x15 pages=6 vmalloc
0xf8959000-0xf895e000   20480 vmalloc_exec+0x13/0x15 pages=4 vmalloc
0xf895e000-0xf8961000   12288 vmalloc_exec+0x13/0x15 pages=2 vmalloc
0xf8961000-0xf8965000   16384 vmalloc_exec+0x13/0x15 pages=3 vmalloc
0xf8965000-0xf8968000   12288 vmalloc_exec+0x13/0x15 pages=2 vmalloc
0xf8968000-0xf896b000   12288 vmalloc_exec+0x13/0x15 pages=2 vmalloc
0xf896b000-0xf8970000   20480 vmalloc_exec+0x13/0x15 pages=4 vmalloc
0xf8970000-0xf8972000    8192 pci_iomap+0xb6/0xc2 phys=edf00000 ioremap
0xf8972000-0xf8974000    8192 __kvm_set_memory_region+0x1c0/0x304 [kvm] pages=1 vmalloc
0xf8974000-0xf8978000   16384 vmalloc_exec+0x13/0x15 pages=3 vmalloc
0xf8978000-0xf897e000   24576 vmalloc_exec+0x13/0x15 pages=5 vmalloc
0xf897e000-0xf8980000    8192 yenta_probe+0x108/0x572 [yenta_socket] phys=e4300000 ioremap
0xf8980000-0xf89a1000  135168 e1000_probe+0x1ad/0xa01 [e1000e] phys=ee000000 ioremap
0xf89a1000-0xf89a7000   24576 vmalloc_exec+0x13/0x15 pages=5 vmalloc
0xf89a7000-0xf89ab000   16384 vmalloc_exec+0x13/0x15 pages=3 vmalloc
0xf89ab000-0xf89b1000   24576 vmalloc_exec+0x13/0x15 pages=5 vmalloc
0xf89b1000-0xf89b5000   16384 vmalloc_exec+0x13/0x15 pages=3 vmalloc
0xf89b6000-0xf89c0000   40960 vmalloc_exec+0x13/0x15 pages=9 vmalloc
0xf89c0000-0xf89c6000   24576 vmalloc_exec+0x13/0x15 pages=5 vmalloc
0xf89c6000-0xf89cb000   20480 vmalloc_exec+0x13/0x15 pages=4 vmalloc
0xf89cb000-0xf89ce000   12288 vmalloc_exec+0x13/0x15 pages=2 vmalloc
0xf89ce000-0xf89d1000   12288 vmalloc_exec+0x13/0x15 pages=2 vmalloc
0xf89d1000-0xf89d4000   12288 vmalloc_exec+0x13/0x15 pages=2 vmalloc
0xf89d4000-0xf89dc000   32768 vmalloc_exec+0x13/0x15 pages=7 vmalloc
0xf89dc000-0xf89df000   12288 e1000e_setup_tx_resources+0x1d/0xba [e1000e] pages=2 vmalloc
0xf89df000-0xf89f8000  102400 vmalloc_exec+0x13/0x15 pages=24 vmalloc
0xf89f8000-0xf89fe000   24576 vmalloc_exec+0x13/0x15 pages=5 vmalloc
0xf89fe000-0xf8a03000   20480 vmalloc_exec+0x13/0x15 pages=4 vmalloc
0xf8a03000-0xf8a07000   16384 vmalloc_exec+0x13/0x15 pages=3 vmalloc
0xf8a07000-0xf8a0c000   20480 drm_ht_create+0x7e/0xbb [drm] pages=4 vmalloc
0xf8a0c000-0xf8a10000   16384 vmalloc_exec+0x13/0x15 pages=3 vmalloc
0xf8a10000-0xf8a14000   16384 vmalloc_exec+0x13/0x15 pages=3 vmalloc
0xf8a14000-0xf8a22000   57344 vmalloc_exec+0x13/0x15 pages=13 vmalloc
0xf8a22000-0xf8a29000   28672 vmalloc_exec+0x13/0x15 pages=6 vmalloc
0xf8a29000-0xf8a2c000   12288 e1000e_setup_rx_resources+0x1d/0xf4 [e1000e] pages=2 vmalloc
0xf8a2c000-0xf8a58000  180224 vmalloc_exec+0x13/0x15 pages=43 vmalloc
0xf8a58000-0xf8a7e000  155648 vmalloc_exec+0x13/0x15 pages=37 vmalloc
0xf8a7e000-0xf8a8b000   53248 vmalloc_exec+0x13/0x15 pages=12 vmalloc
0xf8a8b000-0xf8a95000   40960 vmalloc_exec+0x13/0x15 pages=9 vmalloc
0xf8a95000-0xf8a9e000   36864 vmalloc_exec+0x13/0x15 pages=8 vmalloc
0xf8a9f000-0xf8aaf000   65536 vmalloc_exec+0x13/0x15 pages=15 vmalloc
0xf8ab0000-0xf8ab5000   20480 azx_probe+0x29a/0x88e [snd_hda_intel] phys=ee400000 ioremap
0xf8ab5000-0xf8aba000   20480 drm_ht_create+0x7e/0xbb [drm] pages=4 vmalloc
0xf8aba000-0xf8abe000   16384 vmalloc_exec+0x13/0x15 pages=3 vmalloc
0xf8abe000-0xf8aca000   49152 vmalloc_exec+0x13/0x15 pages=11 vmalloc
0xf8aca000-0xf8adb000   69632 snd_malloc_sgbuf_pages+0x143/0x169 [snd_page_alloc] vmap
0xf8adb000-0xf8aec000   69632 snd_malloc_sgbuf_pages+0x143/0x169 [snd_page_alloc] vmap
0xf8aec000-0xf8afd000   69632 snd_malloc_sgbuf_pages+0x143/0x169 [snd_page_alloc] vmap
0xf8afd000-0xf8b02000   20480 vmalloc_exec+0x13/0x15 pages=4 vmalloc
0xf8b02000-0xf8b06000   16384 vmalloc_exec+0x13/0x15 pages=3 vmalloc
0xf8b06000-0xf8b08000    8192 __kvm_set_memory_region+0x155/0x304 [kvm] pages=1 vmalloc
0xf8b08000-0xf8b13000   45056 vmalloc_exec+0x13/0x15 pages=10 vmalloc
0xf8b13000-0xf8b33000  131072 vmalloc_exec+0x13/0x15 pages=31 vmalloc
0xf8b33000-0xf8b83000  327680 vmalloc_exec+0x13/0x15 pages=79 vmalloc
0xf8b83000-0xf8ba0000  118784 vmalloc_exec+0x13/0x15 pages=28 vmalloc
0xf8ba0000-0xf8bb1000   69632 drm_addmap_core+0x171/0x4bc [drm] phys=ee100000 ioremap
0xf8bb1000-0xf8bb7000   24576 vmalloc_exec+0x13/0x15 pages=5 vmalloc
0xf8bb7000-0xf8bbd000   24576 vmalloc_exec+0x13/0x15 pages=5 vmalloc
0xf8bbd000-0xf8bc0000   12288 vmalloc_exec+0x13/0x15 pages=2 vmalloc
0xf8bc0000-0xf8bc3000   12288 vmalloc_user+0x14/0x4a pages=2 vmalloc user
0xf8bc3000-0xf8bc6000   12288 vmalloc_32+0x13/0x15 pages=2 vmalloc
0xf8bc6000-0xf8bc8000    8192 __kvm_set_memory_region+0x1c0/0x304 [kvm] pages=1 vmalloc
0xf8bc9000-0xf8bcc000   12288 vmalloc_exec+0x13/0x15 pages=2 vmalloc
0xf8bcc000-0xf8bcf000   12288 vmalloc_exec+0x13/0x15 pages=2 vmalloc
0xf8bcf000-0xf8bd4000   20480 vmalloc_exec+0x13/0x15 pages=4 vmalloc
0xf8bd4000-0xf8bd7000   12288 __kvm_set_memory_region+0x1c0/0x304 [kvm] pages=2 vmalloc
0xf8bd7000-0xf8bd9000    8192 __kvm_set_memory_region+0x155/0x304 [kvm] pages=1 vmalloc
0xf8bd9000-0xf8bdd000   16384 vmalloc_exec+0x13/0x15 pages=3 vmalloc
0xf8bdd000-0xf8be0000   12288 vmalloc_exec+0x13/0x15 pages=2 vmalloc
0xf8be0000-0xf8be7000   28672 vmalloc_exec+0x13/0x15 pages=6 vmalloc
0xf8be7000-0xf8c22000  241664 vmalloc_exec+0x13/0x15 pages=58 vmalloc
0xf8c22000-0xf8c47000  151552 vmalloc_exec+0x13/0x15 pages=36 vmalloc
0xf8c47000-0xf9448000 8392704 vmalloc_32+0x13/0x15 pages=2048 vmalloc vpages
0xf9448000-0xf9541000 1019904 sys_swapon+0x485/0xa55 pages=248 vmalloc
0xf9541000-0xf954f000   57344 vmalloc_exec+0x13/0x15 pages=13 vmalloc
0xf954f000-0xf9553000   16384 vmalloc_exec+0x13/0x15 pages=3 vmalloc
0xf9553000-0xf9556000   12288 vmalloc_exec+0x13/0x15 pages=2 vmalloc
0xf9556000-0xf955c000   24576 vmalloc_exec+0x13/0x15 pages=5 vmalloc
0xf955c000-0xf955e000    8192 __kvm_set_memory_region+0x1c0/0x304 [kvm] pages=1 vmalloc
0xf955f000-0xf956c000   53248 vmalloc_exec+0x13/0x15 pages=12 vmalloc
0xf956c000-0xf9576000   40960 vmalloc_exec+0x13/0x15 pages=9 vmalloc
0xf9576000-0xf957b000   20480 vmalloc_exec+0x13/0x15 pages=4 vmalloc
0xf957b000-0xf95a2000  159744 vmalloc_exec+0x13/0x15 pages=38 vmalloc
0xf95a2000-0xf95af000   53248 vmalloc_exec+0x13/0x15 pages=12 vmalloc
0xf95b0000-0xf95b9000   36864 drm_core_ioremap+0x112/0x11d [drm] phys=dbff8000 ioremap
0xf95b9000-0xf95bb000    8192 __kvm_set_memory_region+0x155/0x304 [kvm] pages=1 vmalloc
0xf95bb000-0xf95bd000    8192 __kvm_set_memory_region+0x1c0/0x304 [kvm] pages=1 vmalloc
0xf95bd000-0xf95bf000    8192 __kvm_set_memory_region+0x155/0x304 [kvm] pages=1 vmalloc
0xf95bf000-0xf95c1000    8192 __kvm_set_memory_region+0x1c0/0x304 [kvm] pages=1 vmalloc
0xf95c1000-0xf95c6000   20480 __kvm_set_memory_region+0x155/0x304 [kvm] pages=4 vmalloc
0xf95c6000-0xf95c8000    8192 __kvm_set_memory_region+0x1c0/0x304 [kvm] pages=1 vmalloc
0xf95c9000-0xf95d6000   53248 vmalloc_exec+0x13/0x15 pages=12 vmalloc
0xf95d6000-0xf96d7000 1052672 __kvm_set_memory_region+0x155/0x304 [kvm] pages=256 vmalloc
0xf96d7000-0xf96d9000    8192 __kvm_set_memory_region+0x236/0x304 [kvm] pages=1 vmalloc

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-31  7:16                 ` Nick Piggin
  2008-11-04 17:51                   ` Glauber Costa
@ 2008-11-05  0:21                   ` Glauber Costa
  1 sibling, 0 replies; 24+ messages in thread
From: Glauber Costa @ 2008-11-05  0:21 UTC (permalink / raw)
  To: Nick Piggin
  Cc: Avi Kivity, linux-kernel, kvm, Jeremy Fitzhardinge, Krzysztof Helt

On Fri, Oct 31, 2008 at 08:16:44AM +0100, Nick Piggin wrote:
> On Thu, Oct 30, 2008 at 09:28:54AM -0200, Glauber Costa wrote:
> > On Thu, Oct 30, 2008 at 05:49:41AM +0100, Nick Piggin wrote:
> > > On Wed, Oct 29, 2008 at 08:07:37PM -0200, Glauber Costa wrote:
> > > > On Wed, Oct 29, 2008 at 11:43:33AM +0100, Nick Piggin wrote:
> > > > > On Wed, Oct 29, 2008 at 12:29:40PM +0200, Avi Kivity wrote:
> > > > > > Nick Piggin wrote:
> > > > > > >Hmm, spanning <30MB of memory... how much vmalloc space do you have?
> > > > > > >
> > > > > > >  
> > > > > > 
> > > > > > From the original report:
> > > > > > 
> > > > > > >VmallocTotal:     122880 kB
> > > > > > >VmallocUsed:       15184 kB
> > > > > > >VmallocChunk:      83764 kB
> > > > > > 
> > > > > > So it seems there's quite a bit of free space.
> > > > > > 
> > > > > > Chunk is the largest free contiguous region, right?  If so, it seems the 
> > > > > 
> > > > > Yes.
> > > > > 
> > > > > 
> > > > > > problem is unrelated to guard pages, instead the search isn't finding a 
> > > > > > 1-page area (with two guard pages) for some reason, even though lots of 
> > > > > > free space is available.
> > > > > 
> > > > > Hmm. The free area search could be buggy...
> > > > Do you want me to grab any specific info of it? Or should I just hack myself
> > > > randomly into it? I'll probably have some time for that tomorrow.
> > > 
> > > I took a bit of a look. Does this help you at all?
> > > 
> > > I still think we should get rid of the guard pages in non-debug kernels
> > > completely, but hopefully this will fix your problems?
> > unfortunately, it doesn't.
> > problem still happen in a kernel with this patch.
> 
> That's weird. Any chance you could dump a list of all the vmap area start
> and end adresses and their flags before returning failure?

I said it worked with a single change. Shame on me, I was testing the wrong kernel
it does not work at all. I'll debug it more tomorrow.
> 
> 
> 

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-30  4:49             ` Nick Piggin
  2008-10-30 11:28               ` Glauber Costa
@ 2008-10-30 16:46               ` Matt Mackall
  2008-10-30 18:04                 ` Glauber Costa
  2008-11-07 20:37               ` Glauber Costa
  2 siblings, 1 reply; 24+ messages in thread
From: Matt Mackall @ 2008-10-30 16:46 UTC (permalink / raw)
  To: Nick Piggin
  Cc: Glauber Costa, Avi Kivity, linux-kernel, kvm, aliguori,
	Jeremy Fitzhardinge, Krzysztof Helt

On Thu, 2008-10-30 at 05:49 +0100, Nick Piggin wrote:
> I still think we should get rid of the guard pages in non-debug kernels
> completely,

For what it's worth, I agree.

-- 
Mathematics is the supreme nostalgia of our time.


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-30 16:46               ` Matt Mackall
@ 2008-10-30 18:04                 ` Glauber Costa
  2008-10-31  2:59                   ` Nick Piggin
  0 siblings, 1 reply; 24+ messages in thread
From: Glauber Costa @ 2008-10-30 18:04 UTC (permalink / raw)
  To: Matt Mackall
  Cc: Nick Piggin, Avi Kivity, linux-kernel, kvm, aliguori,
	Jeremy Fitzhardinge, Krzysztof Helt

On Thu, Oct 30, 2008 at 11:46:02AM -0500, Matt Mackall wrote:
> On Thu, 2008-10-30 at 05:49 +0100, Nick Piggin wrote:
> > I still think we should get rid of the guard pages in non-debug kernels
> > completely,
> 
> For what it's worth, I agree.
Do we want any specific option, or is DEBUG_VM enough ?

> 
> -- 
> Mathematics is the supreme nostalgia of our time.
> 

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-30 18:04                 ` Glauber Costa
@ 2008-10-31  2:59                   ` Nick Piggin
  0 siblings, 0 replies; 24+ messages in thread
From: Nick Piggin @ 2008-10-31  2:59 UTC (permalink / raw)
  To: Glauber Costa
  Cc: Matt Mackall, Avi Kivity, linux-kernel, kvm, aliguori,
	Jeremy Fitzhardinge, Krzysztof Helt

On Thu, Oct 30, 2008 at 04:04:43PM -0200, Glauber Costa wrote:
> On Thu, Oct 30, 2008 at 11:46:02AM -0500, Matt Mackall wrote:
> > On Thu, 2008-10-30 at 05:49 +0100, Nick Piggin wrote:
> > > I still think we should get rid of the guard pages in non-debug kernels
> > > completely,
> > 
> > For what it's worth, I agree.
> Do we want any specific option, or is DEBUG_VM enough ?

I'd almost say DEBUG_PAGEALLOC; which could also disable lazy unmapping
in order to catch use-after free better. Or just a different option
entirely.

DEBUG_VM has, so far, been kept to relatively cheap tests that are not
much pain to turn on, and shouldn't result in much behavioural change
of algorithms/data structures AFAIKS. Which can be a good thing.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] regression: vmalloc easily fail.
  2008-10-30  4:49             ` Nick Piggin
  2008-10-30 11:28               ` Glauber Costa
  2008-10-30 16:46               ` Matt Mackall
@ 2008-11-07 20:37               ` Glauber Costa
  2 siblings, 0 replies; 24+ messages in thread
From: Glauber Costa @ 2008-11-07 20:37 UTC (permalink / raw)
  To: Nick Piggin
  Cc: Avi Kivity, linux-kernel, kvm, aliguori, Jeremy Fitzhardinge,
	Krzysztof Helt

On Thu, Oct 30, 2008 at 05:49:41AM +0100, Nick Piggin wrote:
> On Wed, Oct 29, 2008 at 08:07:37PM -0200, Glauber Costa wrote:
> > On Wed, Oct 29, 2008 at 11:43:33AM +0100, Nick Piggin wrote:
> > > On Wed, Oct 29, 2008 at 12:29:40PM +0200, Avi Kivity wrote:
> > > > Nick Piggin wrote:
> > > > >Hmm, spanning <30MB of memory... how much vmalloc space do you have?
> > > > >
> > > > >  
> > > > 
> > > > From the original report:
> > > > 
> > > > >VmallocTotal:     122880 kB
> > > > >VmallocUsed:       15184 kB
> > > > >VmallocChunk:      83764 kB
> > > > 
> > > > So it seems there's quite a bit of free space.
> > > > 
> > > > Chunk is the largest free contiguous region, right?  If so, it seems the 
> > > 
> > > Yes.
> > > 
> > > 
> > > > problem is unrelated to guard pages, instead the search isn't finding a 
> > > > 1-page area (with two guard pages) for some reason, even though lots of 
> > > > free space is available.
> > > 
> > > Hmm. The free area search could be buggy...
> > Do you want me to grab any specific info of it? Or should I just hack myself
> > randomly into it? I'll probably have some time for that tomorrow.
> 
> I took a bit of a look. Does this help you at all?
> 
> I still think we should get rid of the guard pages in non-debug kernels
> completely, but hopefully this will fix your problems?
> --
> 
> - Fix off by one bug in the KVA allocator that can leave gaps 
> - An initial vmalloc failure should start off a synchronous flush of lazy
>   areas, in case someone is in progress flushing them already.
> - Purge lock can be a mutex so we can sleep while that's going on.
>  
> Signed-off-by: Nick Piggin <npiggin@suse.de>
  Tested-by: Glauber Costa <glommer@redhat.com>
> ---
> Index: linux-2.6/mm/vmalloc.c
> ===================================================================
> --- linux-2.6.orig/mm/vmalloc.c
> +++ linux-2.6/mm/vmalloc.c
> @@ -14,6 +14,7 @@
>  #include <linux/highmem.h>
>  #include <linux/slab.h>
>  #include <linux/spinlock.h>
> +#include <linux/mutex.h>
>  #include <linux/interrupt.h>
>  #include <linux/proc_fs.h>
>  #include <linux/seq_file.h>
> @@ -362,7 +363,7 @@ retry:
>  				goto found;
>  		}
>  
> -		while (addr + size >= first->va_start && addr + size <= vend) {
> +		while (addr + size > first->va_start && addr + size <= vend) {
>  			addr = ALIGN(first->va_end + PAGE_SIZE, align);
>  
>  			n = rb_next(&first->rb_node);
> @@ -472,7 +473,7 @@ static atomic_t vmap_lazy_nr = ATOMIC_IN
>  static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
>  					int sync, int force_flush)
>  {
> -	static DEFINE_SPINLOCK(purge_lock);
> +	static DEFINE_MUTEX(purge_lock);
>  	LIST_HEAD(valist);
>  	struct vmap_area *va;
>  	int nr = 0;
> @@ -483,10 +484,10 @@ static void __purge_vmap_area_lazy(unsig
>  	 * the case that isn't actually used at the moment anyway.
>  	 */
>  	if (!sync && !force_flush) {
> -		if (!spin_trylock(&purge_lock))
> +		if (!mutex_trylock(&purge_lock))
>  			return;
>  	} else
> -		spin_lock(&purge_lock);
> +		mutex_lock(&purge_lock);
>  
>  	rcu_read_lock();
>  	list_for_each_entry_rcu(va, &vmap_area_list, list) {
> @@ -518,7 +519,18 @@ static void __purge_vmap_area_lazy(unsig
>  			__free_vmap_area(va);
>  		spin_unlock(&vmap_area_lock);
>  	}
> -	spin_unlock(&purge_lock);
> +	mutex_unlock(&purge_lock);
> +}
> +
> +/*
> + * Kick off a purge of the outstanding lazy areas. Don't bother if somebody
> + * is already purging.
> + */
> +static void try_purge_vmap_area_lazy(void)
> +{
> +	unsigned long start = ULONG_MAX, end = 0;
> +
> +	__purge_vmap_area_lazy(&start, &end, 0, 0);
>  }
>  
>  /*
> @@ -528,7 +540,7 @@ static void purge_vmap_area_lazy(void)
>  {
>  	unsigned long start = ULONG_MAX, end = 0;
>  
> -	__purge_vmap_area_lazy(&start, &end, 0, 0);
> +	__purge_vmap_area_lazy(&start, &end, 1, 0);
>  }
>  
>  /*
> @@ -539,7 +551,7 @@ static void free_unmap_vmap_area(struct 
>  	va->flags |= VM_LAZY_FREE;
>  	atomic_add((va->va_end - va->va_start) >> PAGE_SHIFT, &vmap_lazy_nr);
>  	if (unlikely(atomic_read(&vmap_lazy_nr) > lazy_max_pages()))
> -		purge_vmap_area_lazy();
> +		try_purge_vmap_area_lazy();
>  }
>  
>  static struct vmap_area *find_vmap_area(unsigned long addr)

^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2008-11-07 20:36 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-10-28 22:55 [PATCH] regression: vmalloc easily fail Glauber Costa
2008-10-28 21:03 ` Avi Kivity
2008-10-28 21:09   ` Glauber Costa
2008-10-28 21:22     ` Matias Zabaljauregui
2008-10-28 21:22   ` Roland Dreier
2008-10-28 21:42     ` Arjan van de Ven
2008-10-28 22:03       ` Roland Dreier
2008-10-28 23:29 ` Nick Piggin
2008-10-29  6:28   ` Avi Kivity
2008-10-29  9:48   ` Glauber Costa
2008-10-29 10:11     ` Nick Piggin
2008-10-29 10:29       ` Avi Kivity
2008-10-29 10:43         ` Nick Piggin
2008-10-29 22:07           ` Glauber Costa
2008-10-30  1:53             ` Nick Piggin
2008-10-30  4:49             ` Nick Piggin
2008-10-30 11:28               ` Glauber Costa
2008-10-31  7:16                 ` Nick Piggin
2008-11-04 17:51                   ` Glauber Costa
2008-11-05  0:21                   ` Glauber Costa
2008-10-30 16:46               ` Matt Mackall
2008-10-30 18:04                 ` Glauber Costa
2008-10-31  2:59                   ` Nick Piggin
2008-11-07 20:37               ` Glauber Costa

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).