[lkml]   [2006]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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

    > 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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-10-10 04:25    [W:0.021 / U:222.020 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site