* vmapping user pages - feasible?
@ 2010-02-25 20:05 Zenek
2010-02-25 20:58 ` Christoph Lameter
0 siblings, 1 reply; 4+ messages in thread
From: Zenek @ 2010-02-25 20:05 UTC (permalink / raw)
To: linux-mm
Hello,
my kernel driver gets a userspace pointer to a memory area (virtually
contiguous), allocated by userspace. I would like to use that memory in a
vmalloc-like manner, i.e. I want it to be:
- accessible from kernel
- contiguous in virtual address space
- I may need access from interrupt context as well.
I will be writing to it using the CPU only, in kernel mode.
I understand that:
- no page pinning is required (as only the CPU will be writing to that
area)
- I would be able to use that memory even directly without vmapping, but
only if I didn't want to access it from interrupt context and as long as
it'd be mapped below highmem?
There will be no multithreaded access to that memory.
If the userspace free()s the memory, I still have the pages unless I
vunmap() them, right?
How should I go about it? Get the user's vm_area_struct, go through all
the pages, construct an array of struct *page and vmap it?
Thank you!
Zenek Blus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: vmapping user pages - feasible?
2010-02-25 20:05 vmapping user pages - feasible? Zenek
@ 2010-02-25 20:58 ` Christoph Lameter
2010-02-25 21:22 ` Zenek
2010-02-25 21:38 ` Zenek
0 siblings, 2 replies; 4+ messages in thread
From: Christoph Lameter @ 2010-02-25 20:58 UTC (permalink / raw)
To: Zenek; +Cc: linux-mm
On Thu, 25 Feb 2010, Zenek wrote:
> my kernel driver gets a userspace pointer to a memory area (virtually
> contiguous), allocated by userspace. I would like to use that memory in a
> vmalloc-like manner, i.e. I want it to be:
Its already virtually mapped for the process. The kernel can access the
data.
> I will be writing to it using the CPU only, in kernel mode.
Thats possible already.
> I understand that:
> - no page pinning is required (as only the CPU will be writing to that
> area)
Page pinning is required if the access from the kernel is asynchrononous
to user space.
> There will be no multithreaded access to that memory.
The kernel and userspace are not concurrently accessing the memory?
> If the userspace free()s the memory, I still have the pages unless I
> vunmap() them, right?
If you increase the page count then you still have the pages. The virtual
mapping goes away with the process.
> How should I go about it? Get the user's vm_area_struct, go through all
> the pages, construct an array of struct *page and vmap it?
Do a get_user_pages() on the range?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: vmapping user pages - feasible?
2010-02-25 20:58 ` Christoph Lameter
@ 2010-02-25 21:22 ` Zenek
2010-02-25 21:38 ` Zenek
1 sibling, 0 replies; 4+ messages in thread
From: Zenek @ 2010-02-25 21:22 UTC (permalink / raw)
To: linux-mm
Thank you for your response,
although I'm not sure I've understood...
On Thu, 25 Feb 2010 14:58:52 -0600, Christoph Lameter wrote:
> On Thu, 25 Feb 2010, Zenek wrote:
>> I will be writing to it using the CPU only, in kernel mode.
>>
> Thats possible already.
What about in the interrupt context?
>> I understand that:
>> - no page pinning is required (as only the CPU will be writing to that
>> area)
>
> Page pinning is required if the access from the kernel is asynchrononous
> to user space.
Because simultaneous page faults can happen?
>> There will be no multithreaded access to that memory.
>
> The kernel and userspace are not concurrently accessing the memory?
Could we take into account both cases?
1. not concurrently accessing the memory (e.g. ioctl() call, write by
kernel, return - no more kernel access after return). I can just use the
user mapping, right? What about page faults?
2. concurrently (e.g. ioctl() call, save the pointer in the kernel,
return, asynchronous write by kernel). What then? What happens if user
process calls free() on that area?
>> How should I go about it? Get the user's vm_area_struct, go through all
>> the pages, construct an array of struct *page and vmap it?
>
> Do a get_user_pages() on the range?
Right... so do a get_user_pages(), pass them to vmap(), and write away...
if the process messes up the mapping or dies, it's its fault anyway and
it doesn't get the data, but everything is safe until I call vunmap...
right?
The pages won't get swapped out until I vunmap, and after that even if
they do, they data will get swapped and later restored correctly, right?
Thank you again!
Zenek
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: vmapping user pages - feasible?
2010-02-25 20:58 ` Christoph Lameter
2010-02-25 21:22 ` Zenek
@ 2010-02-25 21:38 ` Zenek
1 sibling, 0 replies; 4+ messages in thread
From: Zenek @ 2010-02-25 21:38 UTC (permalink / raw)
To: linux-mm
On Thu, 25 Feb 2010 14:58:52 -0600, Christoph Lameter wrote:
Ah, and one more question if I may:
Can vmalloc()ed memory be swapped out? From Uderstanding the Linux
Kernel I understand that no kernel memory can be swapped out... Can
anything besides what have been allocated by user be swapped out?
Thank you!
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-02-25 21:38 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-25 20:05 vmapping user pages - feasible? Zenek
2010-02-25 20:58 ` Christoph Lameter
2010-02-25 21:22 ` Zenek
2010-02-25 21:38 ` Zenek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).