Messages in this thread | | | Date | Wed, 14 Jan 2015 14:45:31 -0800 | From | Andrew Morton <> | Subject | Re: [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.
| |