[lkml]   [2006]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subjectptrace and pfn mappings
    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).

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


    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 03:19    [W:0.019 / U:12.572 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site