From patchwork Tue Feb 9 21:25:29 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 78200 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter.kernel.org (8.14.3/8.14.3) with ESMTP id o19LSljM027867 for ; Tue, 9 Feb 2010 21:28:47 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752459Ab0BIV2T (ORCPT ); Tue, 9 Feb 2010 16:28:19 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:45765 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752350Ab0BIV2S (ORCPT ); Tue, 9 Feb 2010 16:28:18 -0500 Received: from imap1.linux-foundation.org (imap1.linux-foundation.org [140.211.169.55]) by smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with ESMTP id o19LPVPr008332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Feb 2010 13:25:32 -0800 Received: from akpm.mtv.corp.google.com (localhost [127.0.0.1]) by imap1.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with SMTP id o19LPT29002636; Tue, 9 Feb 2010 13:25:29 -0800 Date: Tue, 9 Feb 2010 13:25:29 -0800 From: Andrew Morton To: Michael Neuling Cc: KOSAKI Motohiro , Americo Wang , Anton Blanchard , Linus Torvalds , Alexander Viro , Oleg Nesterov , James Morris , Ingo Molnar , linux-fsdevel@vger.kernel.org, stable@kernel.org, linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org, Serge Hallyn , Paul Mackerras , benh@kernel.crashing.org, miltonm@bga.com, aeb@cwi.nl, linux-parisc@vger.kernel.org Subject: Re: [PATCH] Restrict initial stack space expansion to rlimit Message-Id: <20100209132529.bfc455b7.akpm@linux-foundation.org> In-Reply-To: <11046.1265705967@neuling.org> References: <20100208161014.7C6D.A69D9226@jp.fujitsu.com> <1273.1265695885@neuling.org> <20100209154141.03F0.A69D9226@jp.fujitsu.com> <11046.1265705967@neuling.org> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; x86_64-pc-linux-gnu) Mime-Version: 1.0 X-Spam-Status: No, hits=-5.02 required=5 tests=AWL, BAYES_00, OSDL_HEADER_SUBJECT_BRACKETED, PATCH_SUBJECT_OSDL X-Spam-Checker-Version: SpamAssassin 3.2.4-osdl_revision__1.47__ X-MIMEDefang-Filter: lf$Revision: 1.188 $ X-Scanned-By: MIMEDefang 2.63 on 140.211.169.13 Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (demeter.kernel.org [140.211.167.41]); Tue, 09 Feb 2010 21:28:47 +0000 (UTC) --- a/fs/exec.c~fs-execc-restrict-initial-stack-space-expansion-to-rlimit-cleanup-cleanup +++ a/fs/exec.c @@ -637,20 +637,17 @@ int setup_arg_pages(struct linux_binprm * will align it up. */ rlim_stack = rlimit(RLIMIT_STACK) & PAGE_MASK; - if (rlim_stack < stack_size) - rlim_stack = stack_size; + rlim_stack = min(rlim_stack, stack_size); #ifdef CONFIG_STACK_GROWSUP - if (stack_size + stack_expand > rlim_stack) { + if (stack_size + stack_expand > rlim_stack) stack_base = vma->vm_start + rlim_stack; - } else { + else stack_base = vma->vm_end + stack_expand; - } #else - if (stack_size + stack_expand > rlim_stack) { + if (stack_size + stack_expand > rlim_stack) stack_base = vma->vm_end - rlim_stack; - } else { + else stack_base = vma->vm_start - stack_expand; - } #endif ret = expand_stack(vma, stack_base); if (ret) _ > > note: it's untested. > > Works for me on ppc64 with 4k and 64k pages. Thanks! > > I'd still like someone with a CONFIG_STACK_GROWSUP arch to test/ACK it > as well. There's only one CONFIG_GROWSUP arch - parisc. Guys, here's the rolled-up patch. Could someone please test it on parisc? err, I'm not sure what one needs to do to test it, actually. Presumably it involves setting an unusual `ulimit -s'. Can someone please suggest a test plan? From: Michael Neuling When reserving stack space for a new process, make sure we're not attempting to expand the stack by more than rlimit allows. This fixes a bug caused by b6a2fea39318e43fee84fa7b0b90d68bed92d2ba ("mm: variable length argument support") and unmasked by fc63cf237078c86214abcb2ee9926d8ad289da9b ("exec: setup_arg_pages() fails to return errors"). This bug means that when limiting the stack to less the 20*PAGE_SIZE (eg. 80K on 4K pages or 'ulimit -s 79') all processes will be killed before they start. This is particularly bad with 64K pages, where a ulimit below 1280K will kill every process. Signed-off-by: Michael Neuling Cc: KOSAKI Motohiro Cc: Americo Wang Cc: Anton Blanchard Cc: Oleg Nesterov Cc: James Morris Cc: Ingo Molnar Cc: Serge Hallyn Cc: Benjamin Herrenschmidt Cc: fs/exec.c | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff -puN fs/exec.c~fs-execc-restrict-initial-stack-space-expansion-to-rlimit fs/exec.c --- a/fs/exec.c~fs-execc-restrict-initial-stack-space-expansion-to-rlimit +++ a/fs/exec.c @@ -571,6 +571,9 @@ int setup_arg_pages(struct linux_binprm struct vm_area_struct *prev = NULL; unsigned long vm_flags; unsigned long stack_base; + unsigned long stack_size; + unsigned long stack_expand; + unsigned long rlim_stack; #ifdef CONFIG_STACK_GROWSUP /* Limit stack size to 1GB */ @@ -627,10 +630,24 @@ int setup_arg_pages(struct linux_binprm goto out_unlock; } + stack_expand = EXTRA_STACK_VM_PAGES * PAGE_SIZE; + stack_size = vma->vm_end - vma->vm_start; + /* + * Align this down to a page boundary as expand_stack + * will align it up. + */ + rlim_stack = rlimit(RLIMIT_STACK) & PAGE_MASK; + rlim_stack = min(rlim_stack, stack_size); #ifdef CONFIG_STACK_GROWSUP - stack_base = vma->vm_end + EXTRA_STACK_VM_PAGES * PAGE_SIZE; + if (stack_size + stack_expand > rlim_stack) + stack_base = vma->vm_start + rlim_stack; + else + stack_base = vma->vm_end + stack_expand; #else - stack_base = vma->vm_start - EXTRA_STACK_VM_PAGES * PAGE_SIZE; + if (stack_size + stack_expand > rlim_stack) + stack_base = vma->vm_end - rlim_stack; + else + stack_base = vma->vm_start - stack_expand; #endif ret = expand_stack(vma, stack_base); if (ret)