From: Anton Blanchard <anton@samba.org>
To: Michael Neuling <mikey@neuling.org>
Cc: aeb@cwi.nl, linux-kernel@vger.kernel.org, miltonm@bga.com,
linuxppc-dev@ozlabs.org, Paul Mackerras <paulus@samba.org>,
Serge Hallyn <serue@us.ibm.com>,
WANG Cong <xiyou.wangcong@gmail.com>
Subject: Re: Stack size protection broken on ppc64
Date: Sat, 6 Feb 2010 15:20:38 +1100 [thread overview]
Message-ID: <20100206042038.GB32246@kryten> (raw)
In-Reply-To: <3984.1265416993@neuling.org>
Hi,
> On recent ppc64 kernels, limiting the stack (using 'ulimit -s blah') is
> now more restrictive than it was before. On 2.6.31 with 4k pages I
> could run 'ulimit -s 16; /usr/bin/test' without a problem. Now with
> mainline, even 'ulimit -s 64; /usr/bin/test' gets killed.
>
> Using 64k pages is even worse. I can't even run '/bin/ls' with a 1MB
> stack (ulimit -s 1024; /bin/ls). Hence, it seems new kernels are too
> restrictive, rather than the old kernels being too liberal.
It looks like this is causing it:
#define EXTRA_STACK_VM_PAGES 20 /* random */
...
#ifdef CONFIG_STACK_GROWSUP
stack_base = vma->vm_end + EXTRA_STACK_VM_PAGES * PAGE_SIZE;
#else
stack_base = vma->vm_start - EXTRA_STACK_VM_PAGES * PAGE_SIZE;
#endif
Which got added back in 2005 in a memory overcommit patch. It only took 5
years for us to go back and review that random setting :)
The comment from Andries explains the purpose:
(1) It reserves a reasonable amount of virtual stack space (amount
randomly chosen, no guarantees given) when the process is started, so
that the common utilities will not be killed by segfault on stack
extension.
This explains why 64kB is much worse. The extra stack reserve should be in kB
and we also need to be careful not to ask for more than our rlimit.
Anton
next prev parent reply other threads:[~2010-02-06 4:20 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-06 0:43 Stack size protection broken on ppc64 Michael Neuling
2010-02-06 4:20 ` Anton Blanchard [this message]
2010-02-06 10:22 ` Michael Neuling
2010-02-08 0:04 ` Anton Blanchard
2010-02-08 0:07 ` [PATCH] Restrict stack space reservation to rlimit Michael Neuling
2010-02-08 0:28 ` Michael Neuling
2010-02-08 5:06 ` KOSAKI Motohiro
2010-02-08 5:11 ` Anton Blanchard
2010-02-08 5:22 ` KOSAKI Motohiro
2010-02-08 5:31 ` Anton Blanchard
2010-02-08 6:11 ` KOSAKI Motohiro
2010-02-08 5:37 ` Michael Neuling
2010-02-08 6:05 ` KOSAKI Motohiro
2010-02-08 7:07 ` Américo Wang
2010-02-08 7:11 ` KOSAKI Motohiro
2010-02-09 6:11 ` [PATCH] Restrict initial stack space expansion " Michael Neuling
2010-02-09 6:46 ` KOSAKI Motohiro
2010-02-09 8:59 ` Michael Neuling
2010-02-09 21:25 ` Andrew Morton
2010-02-09 21:51 ` Michael Neuling
2010-02-09 22:27 ` Helge Deller
2010-02-10 5:12 ` KOSAKI Motohiro
2010-02-10 5:30 ` Michael Neuling
2010-02-10 5:31 ` Michael Neuling
2010-02-11 22:16 ` Helge Deller
2010-02-11 22:22 ` Michael Neuling
2010-02-08 10:45 ` [PATCH] Restrict stack space reservation " Michael Neuling
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=20100206042038.GB32246@kryten \
--to=anton@samba.org \
--cc=aeb@cwi.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mikey@neuling.org \
--cc=miltonm@bga.com \
--cc=paulus@samba.org \
--cc=serue@us.ibm.com \
--cc=xiyou.wangcong@gmail.com \
/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