linux.git/mm/vmalloc.c, branch v2.6.29

mm: fix lazy vmap purging (use-after-free error)

2009-02-28T00:26:21+00:00

I just got this new warning from kmemcheck:

    WARNING: kmemcheck: Caught 32-bit read from freed memory (c7806a60)
    a06a80c7ecde70c1a04080c700000000a06709c1000000000000000000000000
     f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f
     ^

    Pid: 0, comm: swapper Not tainted (2.6.29-rc4 #230)
    EIP: 0060:[] EFLAGS: 00000286 CPU: 0
    EIP is at __purge_vmap_area_lazy+0x117/0x140
    EAX: 00070f43 EBX: c7806a40 ECX: c1677080 EDX: 00027b66
    ESI: 00002001 EDI: c170df0c EBP: c170df00 ESP: c178830c
     DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
    CR0: 80050033 CR2: c7806b14 CR3: 01775000 CR4: 00000690
    DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
    DR6: 00004000 DR7: 00000000
     [] free_unmap_vmap_area_noflush+0x6e/0x70
     [] remove_vm_area+0x2a/0x70
     [] __vunmap+0x45/0xe0
     [] vunmap+0x1e/0x30
     [] text_poke+0x95/0x150
     [] alternatives_smp_unlock+0x49/0x60
     [] alternative_instructions+0x11b/0x124
     [] check_bugs+0xbd/0xdc
     [] start_kernel+0x2ed/0x360
     [] __init_begin+0x9e/0xa9
     [] 0xffffffff

It happened here:

    $ addr2line -e vmlinux -i c1096df7
    mm/vmalloc.c:540

Code:

	list_for_each_entry(va, &valist, purge_list)
		__free_vmap_area(va);

It's this instruction:

    mov    0x20(%ebx),%edx

Which corresponds to a dereference of va->purge_list.next:

    (gdb) p ((struct vmap_area *) 0)->purge_list.next
    Cannot access memory at address 0x20

It seems that we should use "safe" list traversal here, as the element
is freed inside the loop. Please verify that this is the right fix.

Acked-by: Nick Piggin 
Signed-off-by: Vegard Nossum 
Cc: Pekka Enberg 
Cc: Ingo Molnar 
Cc: "Paul E. McKenney" 
Cc: 		[2.6.28.x]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: vmap fix overflow

2009-02-28T00:26:21+00:00

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 
Reported-by: Christoph Hellwig 
Cc: 		[2.6.28.x]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

vmalloc: call flush_cache_vunmap() from unmap_kernel_range()

2009-02-21T01:57:49+00:00

Impact: proper vcache flush on unmap_kernel_range()

flush_cache_vunmap() should be called before pages are unmapped.  Add
a call to it in unmap_kernel_range().

Signed-off-by: Tejun Heo 
Acked-by: Nick Piggin 
Acked-by: David S. Miller 
Cc: 		[2.6.28.x]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

vmalloc: add __get_vm_area_caller()

2009-02-18T23:37:53+00:00

We have get_vm_area_caller() and __get_vm_area() but not
__get_vm_area_caller()

On powerpc, I use __get_vm_area() to separate the ranges of addresses
given to vmalloc vs.  ioremap (various good reasons for that) so in order
to be able to implement the new caller tracking in /proc/vmallocinfo, I
need a "_caller" variant of it.

(akpm: needed for ongoing powerpc development, so merge it early)

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Benjamin Herrenschmidt 
Reviewed-by: KOSAKI Motohiro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

revert "mm: vmalloc use mutex for purge"

2009-01-16T00:39:40+00:00

Revert commit e97a630eb0f5b8b380fd67504de6cedebb489003 ("mm: vmalloc use
mutex for purge")

Bryan Donlan reports:

: After testing 2.6.29-rc1 on xen-x86 with a btrfs root filesystem, I
: got the OOPS quoted below and a hard freeze shortly after boot.
: Boot messages and config are attached.
:
: ------------[ cut here ]------------
: Kernel BUG at c05ef80d [verbose debug info unavailable]
: invalid opcode: 0000 [#1] SMP
: last sysfs file: /sys/block/xvdc/size
: Modules linked in:
:
: Pid: 0, comm: swapper Not tainted (2.6.29-rc1 #6)
: EIP: 0061:[] EFLAGS: 00010087 CPU: 2
: EIP is at schedule+0x7cd/0x950
: EAX: d5aeca80 EBX: 00000002 ECX: 00000000 EDX: d4cb9a40
: ESI: c12f5600 EDI: d4cb9a40 EBP: d6033fa4 ESP: d6033ef4
:  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069
: Process swapper (pid: 0, ti=d6032000 task=d6020b70 task.ti=d6032000)
: Stack:
:  000d85bc 00000000 000186a0 00000000 0dd11410 c0105417 c12efe00 0dc367c3
:  00000011 c0105d46 d5a5d310 deadbeef d4cb9a40 c07cc600 c05f1340 c12e0060
:  deadbeef d6020b70 d6020d08 00000002 c014377d 00000000 c12f5600 00002c22
: Call Trace:
:  [] xen_force_evtchn_callback+0x17/0x30
:  [] check_events+0x8/0x12
:  [] _spin_unlock_irqrestore+0x20/0x40
:  [] hrtimer_start_range_ns+0x12d/0x2e0
:  [] tick_nohz_restart_sched_tick+0x146/0x160
:  [] cpu_idle+0xa5/0xc0

and bisected it to this commit.

Let's remove it now while we have a think about the problem.

Reported-by: Bryan Donlan 
Tested-by: Christophe Saout 
Cc: Nick Piggin 
Cc: Ingo Molnar 
Cc: Jeremy Fitzhardinge 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

alpha: fix vmalloc breakage

2009-01-16T00:39:35+00:00

On alpha, we have to map some stuff in the VMALLOC space very early in the
boot process (to make SRM console callbacks work and so on, see
arch/alpha/mm/init.c).  For old VM allocator, we just manually placed a
vm_struct onto the global vmlist and this worked for ages.

Unfortunately, the new allocator isn't aware of this, so it constantly
tries to allocate the VM space which is already in use, making vmalloc on
alpha defunct.

This patch forces KVA to import vmlist entries on init.

[akpm@linux-foundation.org: remove unneeded check (per Johannes)]
Signed-off-by: Ivan Kokshaysky 
Cc: Nick Piggin 
Cc: Johannes Weiner 
Cc: Richard Henderson 
Cc: Johannes Weiner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: vmalloc make lazy unmapping configurable

2009-01-06T23:59:01+00:00

Lazy unmapping in the vmalloc code has now opened the possibility for use
after free bugs to go undetected.  We can catch those by forcing an unmap
and flush (which is going to be slow, but that's what happens).

Signed-off-by: Nick Piggin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: vmalloc use mutex for purge

2009-01-06T23:59:01+00:00

The vmalloc purge lock can be a mutex so we can sleep while a purge is
going on (purge involves a global kernel TLB invalidate, so it can take
quite a while).

Signed-off-by: Nick Piggin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: vmalloc improve vmallocinfo

2009-01-06T23:59:01+00:00

If we do that, output of files like /proc/vmallocinfo will show things
like "vmalloc_32", "vmalloc_user", or whomever the caller was as the
caller.  This info is not as useful as the real caller of the allocation.

So, proposal is to call __vmalloc_node node directly, with matching
parameters to save the caller information

Signed-off-by: Glauber Costa 
Signed-off-by: Nick Piggin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: vmalloc tweak failure printk

2009-01-06T23:59:01+00:00

If we can't service a vmalloc allocation, show size of the allocation that
actually failed.  Useful for debugging.

Signed-off-by: Glauber Costa 
Signed-off-by: Nick Piggin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds