Re: Ambigiuous thread stack annotation in /proc/pid/[s]maps

[Jan Glauber]

On Wed, Jun 26, 2013 at 10:05:41PM +0530, Siddhesh Poyarekar wrote:
> On 26 June 2013 17:13, Jan Glauber <jan.glauber@xxxxxxxxx> wrote:
> > Any ideas how that can be fixed? The only solution that comes to my mind
> > is to prevent merging vma's that are used for thread stacks. There is already a
> > flag (MAP_STACK) which is set by the libc for mmap'ing thread stacks but the
> > kernel currently does not care. If the kernel gets an mmap request with
> > MAP_STACK set we could mark the VMA and avoid merging it with others.
> >
> > Unfortunately there seems to be no bit left in the vm_flags to store the
> > MAP_STACK information...
> 
> The annotations essentially point out that the vma contains the stack
> and not that the vma *is* the stack.  We'd get similar output with

But isn't that confusing to the user? At least it is to me. Imagine someone
who uses the maps or smaps output to determine the size of code, data and
stack of a process. Maybe it would be better to not print the stack:tid data
at all if the kernel cannot distinguish the vma's?
Is that behaviour documented anywhere?

> makecontext/getcontext, where the stack may just be a portion of
> memory in another vma.  I don't remember if I had explicitly mentioned
> that during the original discussion.

Never seen that makecontext stuff before. Do you have an example output how
the maps would look like if that is used?

--Jan
 
> Siddhesh
> --
> http://siddhesh.in
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/