]> nv-tegra.nvidia Code Review - linux-2.6.git/commit
mspec: handle shrinking virtual memory areas
authorCliff Wickman <cpw@sgi.com>
Wed, 19 Sep 2007 05:46:31 +0000 (22:46 -0700)
committerLinus Torvalds <torvalds@woody.linux-foundation.org>
Wed, 19 Sep 2007 18:24:17 +0000 (11:24 -0700)
commit4191ba26dae8338892e73f6e67bd18068b4344e9
tree150cbb20ba7b2c1e73b378df22c8179425ace848
parent49cc886aea1d79cdb0ea409554866238b07fe26f
mspec: handle shrinking virtual memory areas

The shrinking of a virtual memory area that is mmap(2)'d to a memory
special file (device drivers/char/mspec.c) can cause a panic.

If the mapped size of the vma (vm_area_struct) is very large, mspec allocates
a large vma_data structure with vmalloc(). But such a vma can be shrunk by
an munmap(2).  The current driver uses the current size of each vma to
deduce whether its vma_data structure was allocated by kmalloc() or vmalloc().
So if the vma was shrunk it appears to have been allocated by kmalloc(),
and mspec attempts to free it with kfree().  This results in a panic.

This patch avoids the panic (by preserving the type of the allocation) and
also makes mspec work correctly as the vma is split into pieces by the
munmap(2)'s.

All vma's derived from such a split vma share the same vma_data structure that
represents all the pages mapped into this set of vma's.  The mpec driver
must be made capable of using the right portion of the structure for each
member vma.  In other words, it must index into the array of page addresses
using the portion of the array that represents the current vma. This is
enabled by storing the vma group's vm_start in the vma_data structure.

The shared vma_data's are not protected by mm->mmap_sem in the fork() case
so the reference count is left as atomic_t.

Signed-off-by: Cliff Wickman <cpw@sgi.com>
Acked-by: Jes Sorensen <jes@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
drivers/char/mspec.c