public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Stefani Seibold <stefani@seibold.net>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Ingo Molnar <mingo@elte.hu>
Subject: Re: [merged] proctxt-update-kernel-filesystem-proctxt-documentation.patch removed from -mm tree
Date: Wed, 24 Jun 2009 00:13:02 -0700	[thread overview]
Message-ID: <20090624001302.18de9e21.akpm@linux-foundation.org> (raw)
In-Reply-To: <1245825903.23818.4.camel@wall-e>

On Wed, 24 Jun 2009 08:45:03 +0200 Stefani Seibold <stefani@seibold.net> wrote:

> Am Dienstag, den 23.06.2009, 23:32 -0700 schrieb Andrew Morton:
> > On Wed, 24 Jun 2009 08:20:44 +0200 Stefani Seibold <stefani@seibold.net> wrote:
> > 
> > > what is with the associated
> > > procfs-provide-stack-information-for-threads-v08.patch
> > > patch?
> > > 
> > > There was no real objections against this patch, so why not merge it for
> > > 2.6.31?
> > 
> > Alexey pointed out that it doesn't actually work.
> 
> That is not true... it works. With my patch the kernel does exactly know
> where the thread stack is and therefor it is easy to determinate the
> associated map.
> 

On Tue, 16 Jun 2009 02:33:33 +0400 Alexey Dobriyan <adobriyan@gmail.com> wrote:

> On Mon, Jun 15, 2009 at 03:02:05PM -0700, akpm@linux-foundation.org wrote:
> >      procfs-provide-stack-information-for-threads-v08.patch
> > --- a/fs/proc/array.c~procfs-provide-stack-information-for-threads-v08
> 
> > +++ a/fs/proc/array.c
> > @@ -321,6 +321,54 @@ static inline void task_context_switch_c
> >  			p->nivcsw);
> >  }
> >  
> > +static inline unsigned long get_stack_usage_in_bytes(struct vm_area_struct *vma,
> > +					struct task_struct *p)
> > +{
> > +	unsigned long	i;
> > +	struct page	*page;
> > +	unsigned long	stkpage;
> > +
> > +	stkpage = KSTK_ESP(p) & PAGE_MASK;
> > +
> > +#ifdef CONFIG_STACK_GROWSUP
> > +	for (i = vma->vm_end; i-PAGE_SIZE > stkpage; i -= PAGE_SIZE) {
> > +
> > +		page = follow_page(vma, i-PAGE_SIZE, 0);
> 
> How can this work?
> 
> If stack page got swapped out, you'll get smaller than actual result.

Alexey's point is that follow_page() will return NULL if it hits a
swapped-out stack page and the loop will exit, leading to an incorrect
(ie: short) return value from get_stack_usage_in_bytes().

Is this claim wrong?

  reply	other threads:[~2009-06-24  7:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200906182243.n5IMhwuV003008@imap1.linux-foundation.org>
     [not found] ` <1245824444.22613.3.camel@wall-e>
     [not found]   ` <20090623233247.7ed661b7.akpm@linux-foundation.org>
2009-06-24  6:45     ` [merged] proctxt-update-kernel-filesystem-proctxt-documentation.patch removed from -mm tree Stefani Seibold
2009-06-24  7:13       ` Andrew Morton [this message]
2009-06-24  7:35         ` Eric W. Biederman
2009-06-24  9:33           ` Stefani Seibold
2009-06-24 15:30             ` Andrew Morton
2009-06-24 15:57               ` Stefani Seibold
2009-06-24 12:03           ` [patch 2/2] procfs: provide stack information for threads V0.9 Stefani Seibold
2009-06-24 14:33           ` [patch 2/2] procfs: provide stack information for threads V0.10 Stefani Seibold
2009-06-24 15:20             ` Ingo Molnar
2009-06-24 15:49               ` Stefani Seibold
2009-06-24 17:40                 ` Johannes Weiner
2009-06-24 17:46                   ` Ingo Molnar
2009-06-24 19:08                     ` Johannes Weiner
2009-06-25  9:36                       ` Ingo Molnar
2009-06-25 10:09                       ` [tip:perfcounters/urgent] perf record: Fix filemap pathname parsing in /proc/pid/maps tip-bot for Johannes Weiner
2009-06-24 16:28           ` [patch 2/2] procfs: provide stack information for threads V0.11 Stefani Seibold

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090624001302.18de9e21.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=adobriyan@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=stefani@seibold.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox