copy_from_user problem

Maynard Johnson maynardj at us.ibm.com
Wed Feb 27 23:27:57 EST 2008


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.
>
>
>   





More information about the Linuxppc-dev mailing list