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@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>