linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Maynard Johnson <maynardj@us.ibm.com>
To: benh@kernel.crashing.org
Cc: linuxppc-dev@ozlabs.org
Subject: Re: copy_from_user problem
Date: Wed, 27 Feb 2008 06:27:57 -0600	[thread overview]
Message-ID: <47C5574D.2090409@us.ibm.com> (raw)
In-Reply-To: <1204068146.15052.188.camel@pasglop>

Benjamin Herrenschmidt wrote:
> On Tue, 2008-02-26 at 08:49 -0600, Maynard Johnson wrote:
>   
>> 2. Compile C program as 32-bit; then run it.  While the program is 
>> waiting for input, obtain its PID and do 'cat /proc/<pid>/maps' to
>> get 
>> the address of where libc is loaded.
>> 3. From the dir where you build the uaccess_test kernel module:
>>          'insmod ./uaccess_test.ko lib_addr=0x<mem_loc_libc>'
>>     This should succeed.  dmesg to verify.
>> 4. Unload the module.
>> 5. Recompile your C program with -m64; start it up and obtain the 
>> address of libc again (now a 64-bit address).
>> 6. Load the uaccess_test kernel module and pass 
>> 'lib_addr=0x<mem_loc_libc>'.  Note that this time, the load fails. 
>> dmesg to see debug printk's.
>>     
>
> Sounds to me that your kernel module will try to copy_from_user() from
> the user context of ... insmod :-)
>   
Yeah, that's probably the problem (along with my lack of understanding 
how VM works  -- heh).  I guess I was just getting lucky with the 32-bit 
test in that the 32-bit libc was being loaded for my insmod process at 
the same virtual memory address as for my C test program.
> You need to do your copy_from_user() from within the context of the
> program you try to access the memory from !
>   
Can't do that in the "real" code I'm developing, so I guess I'll need to 
use get_user_pages.  Hmmm . . . not quite as simple to use as 
copy_from_user, and I don't see any doc on it.  But at least I've found 
a couple examples in the kernel tree.
> If you need to access another context than the current one, you then
> need to use a different mechanism, such as get_user_pages(), though
> beware that you can only do that for memory, not SPE local store or
> register mappings.
>   
The "real" code I'm developing is targeted at POWER, not Cell.

Thanks, Ben!

-Maynard
> Ben.
>
>
>   

  reply	other threads:[~2008-02-27 12:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-26  1:47 copy_from_user problem Maynard Johnson
2008-02-26  2:56 ` Benjamin Herrenschmidt
2008-02-26 14:49   ` Maynard Johnson
2008-02-26 15:01     ` Nathan Lynch
2008-02-26 15:30       ` Nathan Lynch
2008-02-26 15:36       ` Maynard Johnson
2008-02-26 23:22     ` Benjamin Herrenschmidt
2008-02-27 12:27       ` Maynard Johnson [this message]
2008-02-27 12:40         ` Arnd Bergmann
2008-02-27 20:24         ` Benjamin Herrenschmidt
2008-02-26  5:29 ` Paul Mackerras
  -- strict thread matches above, loose matches on Subject: below --
2005-08-11  2:52 V MURAHARI
2005-08-11 11:02 ` Clemens Koller
2005-08-11 14:29 ` T Michael Turney

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=47C5574D.2090409@us.ibm.com \
    --to=maynardj@us.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.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 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).