linux-kernel - Re: + procfs-provide-stack-information-for-threads-v08.patch added to -mm tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 17 Jun 2009 01:30:04 +0400
From:	Alexey Dobriyan <adobriyan@...il.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Stefani Seibold <stefani@...bold.net>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, a.p.zijlstra@...llo.nl, mingo@...e.hu
Subject: Re: + procfs-provide-stack-information-for-threads-v08.patch added
	to -mm tree

On Tue, Jun 16, 2009 at 12:39:28PM -0700, Eric W. Biederman wrote:
> Stefani Seibold <stefani@...bold.net> writes:
> 
> > Am Dienstag, den 16.06.2009, 02:33 +0400 schrieb Alexey Dobriyan:
> >> On Mon, Jun 15, 2009 at 03:02:05PM -0700, akpm@...ux-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.
> >> 
> >
> > If you tell me how to do it in the right way, i can fix it!
> 
> You are attempting to answer two questions here.
> 1) Where do the thread stacks reside.

Kernel doesn't know. Application stack is somewhere below/above
some SP register.

> 2) What is the maximum stack space that has been used.
> 
> Just listing the thread stacks seems like a small O(1) change.
> 
> Computing how much stack space has been used looks trickier.
> Perhaps you could map them with MAP_GROWSDOWN?  Of course that
> has the problem that you don't stop growing your stack until
> it bumps into something else.  Not ideal for a thread stack.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/