lkml.org 
[lkml]   [2015]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH] procfs: Add /proc/<pid>/mapped_files
    On Wed, 14 Jan 2015 13:03:26 -0800 Calvin Owens <calvinowens@fb.com> wrote:

    > > Well, only when combined with checking vm_file for being NULL. One would
    > > also need to ensure that vm_pgoff is 0 for any non-stack,
    > > non-file-backed VMA. At which point it is somewhat ugly.
    > >
    > > > One problem with caching the value on clone like this though is that
    > > > the stack could change due to a setcontext, but AFAICT we don't care
    > > > about that for the process stack either.
    > >
    > > If it is important, I guess one could update the info when a task calls
    > > setcontext.
    >
    > If I understand the current behavior, the "[stack]" marker will get put
    > next to *any* mapping that encompasses the current value in the task's
    > %sp, regardless of how the mapping was created or ucontext stuff. If
    > you use flags on the VMA structs things could potentially be marked as
    > stacks even though %sp points somewhere else.
    >
    > It's probable that nobody cares (you'd obviously have to be doing crazy
    > things to be pointing %sp at arbitrary places), but that's why I was
    > hesitant to mess with it.

    Fixing the N^2 search would of course be much better than adding a new
    proc file to sidestep it.

    Could we do something like refreshing the new vma.vm_flags:VM_IS_STACK
    on each thread at the time when /proc/PID/maps is opened? So do a walk
    of the threads, use each thread's sp to hunt down the thread's stack's
    vma, then set VM_IS_STACK and fill in the new vma.stack_tid field?

    There are still several flags unused in vma.vm_flags btw.

    I'm not sure that we can repurpose vm_pgoff (or vm_private_data) for
    this: a badly behaved thread could make its sp point at a random vma
    then trick the kernel into scribbling on that vma's vm_proff? Adding a
    new field to the vma wouldn't kill us, I guess. That would remove the
    need for a VM_IS_STACK.




    \
     
     \ /
      Last update: 2015-01-15 00:01    [W:3.128 / U:0.116 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site