linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* 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).