Messages in this thread | | | Date | Tue, 10 Oct 2006 04:23:10 +0200 | From | Nick Piggin <> | Subject | Re: ptrace and pfn mappings |
| |
On Tue, Oct 10, 2006 at 11:16:27AM +1000, Benjamin Herrenschmidt wrote: > And the last of my "issues" here: > > get_user_pages() can't handle pfn mappings, thus access_process_vm() > can't, and thus ptrace can't. When they were limited to dodgy /dev/mem > things, it was probably ok. But with more drivers needing that, like the > DRM, sound drivers, and now with SPU problem state registers and local > store mapped that way, it's becoming a real issues to be unable to > access any of those mappings from gdb. > > The "easy" way out I can see, but it may have all sort of bad side > effects I haven't thought about at this point, is to switch the mm in > access_process_vm (at least if it's hitting such a VMA).
Switch the mm and do a copy_from_user? (rather than the GUP). Sounds pretty ugly :P
Can you do a get_user_pfns, and do a copy_from_user on the pfn addresses? In other words, is the memory / mmio at the end of a given address the same from the perspective of any process? It is for physical memory of course, which is why get_user_pages works...
> That means that the ptracing process will temporarily be running in the > kernel using a task->active_mm different from task->mm which might have > funny side effects due to assumptions that this won't happen here or > there, though I don't see any fundamental reasons why it couldn't be > made to work. > > That do you guys think ? Any better idea ? The problem with mappings > like what SPUfs or the DRM want is that they can change (be remapped > between HW and backup memory, as described in previous emails), thus we > don't want to get struct pages even if available and peek at them as > they might not be valid anymore, same with PFNs (we could imagine > ioremap'ing those PFN's but that would be racy too). The only way that > is guaranteed not to be racy is to do exactly what a user do, that is do > user accesses via the target process vm itself....
What if you hold your per-object lock over the operation? (I guess it would have to nest *inside* mmap_sem, but that should be OK). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |