All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Veltzer <mark.veltzer@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: get_user_pages question
Date: Mon, 9 Nov 2009 08:50:25 +0200	[thread overview]
Message-ID: <200911090850.26724.mark.veltzer@gmail.com> (raw)

Hello all!

I have searched the list for similar issues and have not found an answer so I 
am posting.

I am using 'get_user_pages' and friends to get a hold of user memory in kernel 
space. User space passes buffer to kernel, kernel does get_user_pages, holds 
them for some time while user space is doing something else, writes to the 
pages and then releases them (SetPageDirty and page_cache_release as per LDD 
3rd edition). So far so good. 

I am testing this kernel module with several buffers from user space allocated 
in several different ways. heap, data segment, static variable in function and 
stack. All scenarious work EXCEPT the stack one. When passing the stack buffer 
the kernel sees one thing while user space sees another.

My not so intelligent questions (they may well be off the mark):
- How can this be? (two views of the same page)
- Does not 'get_user_pages' pin the pages?
- Could this be due to stack protection of some sort?
- Do I need to do anything extra with the vm_area I receive for the stack 
pages EXCEPT 'get_user_pages' ?

I know this is not an orthodox method to write a driver and I better use mmap 
for these things but I have other constrains in this driver design that I do 
not want to bore you with. I am also awara that passing a buffer on stack and 
letting user space continue running is a very dangerous thing to do for user 
space (or kernel space) integrity. I wish I could do it another way...

The platform is x86 32 bit standad with standard kernels and headers 
distributed with ubuntu 9.04 and 9.10 which are 2.6.28 and 2.6.31.

Please reply to my email as well as I am not a subscriber.

Cheers,
	Mark

             reply	other threads:[~2009-11-09  6:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-09  6:50 Mark Veltzer [this message]
2009-11-09  9:31 ` get_user_pages question Andi Kleen
2009-11-09 10:32   ` Hugh Dickins
2009-11-09 22:13     ` Mark Veltzer
2009-11-10 16:33       ` Hugh Dickins
2009-11-28 18:50         ` Andrea Arcangeli
2009-11-28 22:22           ` Mark Veltzer
2009-11-30 12:01             ` Nick Piggin
2009-11-30 16:12               ` Andrea Arcangeli
2009-11-30 11:54           ` Nick Piggin
  -- strict thread matches above, loose matches on Subject: below --
2004-05-01 11:12 Eli Cohen
2004-05-01 11:32 ` Arjan van de Ven
2004-05-01 11:41   ` Eli Cohen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200911090850.26724.mark.veltzer@gmail.com \
    --to=mark.veltzer@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.