Re: How to map user space's virtual memory into kernel logical address space

From: Robert Hancock
Date: Wed Nov 28 2007 - 19:34:43 EST


Maitre Bart wrote:
A given app is allocating a large amount of memory (~10M) with
malloc().
It passes this pointer to the kernel (device driver) via an custom
ioctl.
I would like the driver to work on that memory with a pointer (as if
it was allocated with vmalloc) as well as the user space too (upon
return of the syscall).
Is there a way to map a user space's virtual memory range into the
kernel logical address space?

As far as I learned from my readings, using the user-space pointer
directly in kernel space will not work.

Of course, copy_from_user() is out of question for efficiency
purposes.

ioremap() is pretty close to what I wish to do except that it accepts
a physical address and I don't how to get it from a user space
pointer. And since a physical address is required, I assume the range
is considered contiguous, which is not really the case for malloc().

mmap()/remap_pfn_range() are interesting but I don't know how to get a
kernel pointer out of them.

kmap() does the job for a single page (and anyway, I wouldn't know how
to feed it with a struct page from the userland pointer).

get_user_pages() looks promising but it seems I have to call kmap() on
each page, so it looks like I cannot operate on the buffer with a
single pointer.

Does any one know if it is possible? And if so, how can I do it?

10MB is an awfully big mapping to put into kernel virtual memory space. I suspect it might be easier to allocate the memory in the kernel and map it in from userspace, but then you have the same problem (and 10MB is awfully big for vmalloc).

Is there a good reason why you have to be able to do this? There's likely a better way.

--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@xxxxxxxxxxxxx
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/