Messages in this thread | | | Date | Thu, 12 Feb 2009 02:39:31 +0100 | From | Nick Piggin <> | Subject | Re: [patch] mm: vmap fix overflow |
| |
On Tue, Feb 10, 2009 at 02:44:20PM -0800, Andrew Morton wrote: > On Tue, 10 Feb 2009 06:51:19 +0100 > Nick Piggin <npiggin@suse.de> wrote: > > > This patch is appropriate for 2.6.28 too. > > > > -- > > > > The new vmap allocator can wrap the address and get confused in the case of > > large allocations or VMALLOC_END near the end of address space. > > > > Problem reported by Christoph Hellwig on a 32-bit XFS workload. > > > > Signed-off-by: Nick Piggin <npiggin@suse.de> > > --- > > mm/vmalloc.c | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > Index: linux-2.6/mm/vmalloc.c > > =================================================================== > > --- linux-2.6.orig/mm/vmalloc.c > > +++ linux-2.6/mm/vmalloc.c > > @@ -334,6 +334,9 @@ retry: > > addr = ALIGN(vstart, align); > > > > spin_lock(&vmap_area_lock); > > + if (addr + size < addr) > > + goto overflow; > > + > > /* XXX: could have a last_hole cache */ > > n = vmap_area_root.rb_node; > > if (n) { > > @@ -365,6 +368,8 @@ retry: > > > > while (addr + size > first->va_start && addr + size <= vend) { > > addr = ALIGN(first->va_end + PAGE_SIZE, align); > > + if (addr + size < addr) > > + goto overflow; > > > > n = rb_next(&first->rb_node); > > if (n) > > @@ -375,6 +380,7 @@ retry: > > } > > found: > > if (addr + size > vend) { > > +overflow: > > spin_unlock(&vmap_area_lock); > > if (!purged) { > > purge_vmap_area_lazy(); > > well... > > > If a caller tries to allocate 0x1000 bytes at address 0xfffff000, this > code will think that it overflowed. But it didn't. > > Presumably nobody ever tries to do that, but it seems a bit sloppy?
Oh that's true, good catch. I guess that should be (addr + size - 1)? Because we care about the last byte that was actually allocated to us (inclusive, rather than exclusive).
| |