[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20061102120412.bc25e2d0.akpm@osdl.org>
Date: Thu, 2 Nov 2006 12:04:12 -0800
From: Andrew Morton <akpm@...l.org>
To: "Miguel Ojeda" <maxextreme@...il.com>
Cc: Franck <vagabon.xyz@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH update6] drivers: add LCD support
On Thu, 2 Nov 2006 19:33:48 +0000
"Miguel Ojeda" <maxextreme@...il.com> wrote:
> May 2.6.18-new vmalloc
> related functions help correlating userspace & kernel addresses? I
> will try them and come with an answer tomorrow.
>
> Quoting http://lwn.net/Articles/2.6-kernel-api/
>
> "Some functions have been added to make it easy for kernel code to
> allocate a buffer with vmalloc() and map it into user space. They are:
>
> void *vmalloc_user(unsigned long size);
> void *vmalloc_32_user(unsigned long size);
> int remap_vmalloc_range(struct vm_area_struct *vma, void *addr,
> unsigned long pgoff);
>
> The first two functions are a form of vmalloc() which obtain memory
> intended to be mapped into user space; among other things, they zero
> the entire range to avoid leaking data. vmalloc_32_user() allocates
> low memory only. A call to remap_vmalloc_range() will complete the
> job; it will refuse, however, to remap memory which has not been
> allocated with one of the two functions above."
No, it doesn't look like those helper functions are designed to handle this.
I'm really not the person to be asking about this. I can poke around in
arch/sparc64/kernel/sys_sparc.c:arch_get_unmapped_area() as well as the
next guy, and it seems to be doing the right thing for MAP_FIXED, but
how/whether it handles !MAP_FIXED I do not know. Ask davem ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists