[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAHN_R2q23-gN43j52X231k0Xs-D_x5KofEMGq_npdWCWVpuyA@mail.gmail.com>
Date: Wed, 20 Jan 2016 08:51:38 +0530
From: Siddhesh Poyarekar <siddhesh.poyarekar@...il.com>
To: "Kirill A. Shutemov" <kirill@...temov.name>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Johannes Weiner <hannes@...xchg.org>, Shaohua Li <shli@...com>,
linux-mm@...ck.org, linux-kernel <linux-kernel@...r.kernel.org>,
kernel-team@...com
Subject: Re: [PATCH] proc: revert /proc/<pid>/maps [stack:TID] annotation
On 20 January 2016 at 05:00, Kirill A. Shutemov <kirill@...temov.name> wrote:
> I doubt it can be very useful as it's unreliable: if two stacks are
> allocated end-to-end (which is not good idea, but still) it can only
> report [stack:XXX] for the first one as they are merged into one VMA.
> Any other anon VMA merged with the stack will be also claimed as stack,
> which is not always correct.
It is quite uncommon because you will always have an intervening guard
page that separates the two stack vmas. To have the vmas merge, you
will have to disable guard pages which is an even worse idea.
A more relevant argument about its unreliability is context changes
due to makecontext/setcontext, which could momentarily show the heap
or some other arbitrary vma as a stack.
Siddhesh
--
http://siddhesh.in
Powered by blists - more mailing lists