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. > > > _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
