Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752733Ab3FZQfo (ORCPT ); Wed, 26 Jun 2013 12:35:44 -0400 Received: from mail-oa0-f49.google.com ([209.85.219.49]:51670 "EHLO mail-oa0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751516Ab3FZQfm (ORCPT ); Wed, 26 Jun 2013 12:35:42 -0400 MIME-Version: 1.0 In-Reply-To: <20130626114324.GA3538@hal> References: <20130626114324.GA3538@hal> Date: Wed, 26 Jun 2013 22:05:41 +0530 Message-ID: Subject: Re: Ambigiuous thread stack annotation in /proc/pid/[s]maps From: Siddhesh Poyarekar To: Jan Glauber Cc: linux-kernel Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1140 Lines: 24 On 26 June 2013 17:13, Jan Glauber 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 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. Siddhesh -- http://siddhesh.in -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/