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