Skip to content
  • Cliff Wickman's avatar
    mspec: handle shrinking virtual memory areas · 4191ba26
    Cliff Wickman authored
    
    
    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: default avatarCliff Wickman <cpw@sgi.com>
    Acked-by: default avatarJes Sorensen <jes@sgi.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    4191ba26