Re: [patch 1/5] mm: remap_vmalloc_range

[Andrew Morton <akpm@osdl.org>]

Nick Piggin <npiggin@suse.de> wrote:
>
>  +/**
>  + *	remap_vmalloc_range  -  map vmalloc pages to userspace
>  + *
>  + *	@vma:		vma to cover (map full range of vma)
>  + *	@addr:		vmalloc memory
>  + *	@pgoff:		number of pages into addr before first page to map
>  + *	@returns:	0 for success, -Exxx on failure
>  + *
>  + *	This function checks that addr is a valid vmalloc'ed area, and
>  + *	that it is big enough to cover the vma. Will return failure if
>  + *	that criteria isn't met.
>  + *
>  + *	Similar to remap_pfn_range (see mm/memory.c)
>  + */

When replacing calls to remap_pfn_rage() with calls to remap_valloc_range():

- remap_pfn_range() sets VM_IO|VM_RESERVED|VM_PFNMAP on the user's vma. 
  remap_valloc_range() sets only VM_RESERVED.

- remap_pfn_range() has special handling for COWable user vma's, but
  remap_valloc_range() does not.

- are vma->vm_start and vma->vm_end always a multiple of PAGE_SIZE?  (I
  always forget).  If not, remap_valloc_range() looks a tad buggy.


pls explain.


- remap_valloc_range() can use ~PAGE_MASK, not PAGE_SIZE-1

- remap_valloc_range() would lose a whole buncha typecasts if you use the
  gcc pointer-arith-with-void* extension.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/