Bug 15308

Summary: 2.6.33-rc8 breaks UML with Restrict initial stack space expansion to rlimit
Product: Platform Specific/Hardware Reporter: Rafael J. Wysocki (rjw)
Component: UMLAssignee: Jeff Dike (jdike)
Status: CLOSED CODE_FIX    
Severity: normal CC: j, kosaki.motohiro, maciej.rutecki, mikey
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.33-rc8 Subsystem:
Regression: Yes Bisected commit-id:
Bug Depends on:    
Bug Blocks: 14885    

Description Rafael J. Wysocki 2010-02-14 23:20:17 UTC 
Subject    : 2.6.33-rc8 breaks UML with Restrict initial stack space expansion to rlimit
Submitter  : Jouni Malinen <j@w1.fi>
Date       : 2010-02-14 16:40
Message-ID : 20100214164023.GA2726@jm.kir.nu
References : http://marc.info/?l=linux-kernel&m=126616751807902&w=4
Handled-By : Michael Neuling <mikey@neuling.org>

This entry is being used for tracking a regression from 2.6.32.  Please don't
close it until the problem is fixed in the mainline.
Comment 1 Rafael J. Wysocki 2010-02-14 23:21:46 UTC 
Reportedly caused by:

commit 803bf5ec259941936262d10ecc84511b76a20921
Author: Michael Neuling <mikey@neuling.org>
Date:   Wed Feb 10 13:56:42 2010 -0800

    fs/exec.c: restrict initial stack space expansion to rlimit

    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

First-Bad-Commit : 803bf5ec259941936262d10ecc84511b76a20921
Comment 2 Jouni Malinen 2010-02-15 07:04:43 UTC 
With 803bf5 included, init=/bin/sh seems to fail the boot quite
frequently, but not always. Once I get to shell on the UML guest,
/bin/ls fails about half of the time (e.g., running /bin/ls in /root
failed six times out of ten). This was before touching ulimit -s at all
("ulimit -s" shows 8192).

The behavior of 'ls' run with various ulimit -s values:

24-10000: OK or Killed
16-23: OK or Segmentation fault or Killed
1-15: Killed or Segmentation fault

I have no idea what is causing the random behavior in the results, but
anyway, it looks like 'ulimit -s 23' is the first point where
segmentation faults start showing up and 'ulimit -s 15' is the point
where ls fails every time.


If I start the guest (normal boot with multiple virtual consoles) with
803bf5 reverted, 'ulimit -s 84' has /bin/ls working every time and
'ulimit -s 83' makes it fail every time.


---

The SIGKILL part is the odd one, I would assume.. It looks like about
half of the commands are failing with SIGKILL even with ulimit -s 8192
and the ulimit -s value did not really change the failure rate that
much if at all. SIGSEGV starts showing up only after having limited
ulimit -s to quite samll number (see my previous email).

% /usr/bin/time --format="mem %M" ls
mem 3296

% sudo /usr/bin/time --format="mem %M"  mount -a
mem 2928
Comment 3 Rafael J. Wysocki 2010-02-15 21:11:10 UTC 
Handled-By : Michael Neuling <mikey@neuling.org>
Patch : http://patchwork.kernel.org/patch/79365/
Comment 4 Michael Neuling 2010-02-23 21:37:26 UTC 
This is now upstream as a17e18790a8c47113a73139d54a375dc9ccd8f08 (fs/exec.c: fix initial stack reservation).
Comment 5 Rafael J. Wysocki 2010-02-23 22:49:16 UTC 
Thanks, closing.
Comment 6 Michael Neuling 2010-02-23 23:56:19 UTC 
FYI this is going to effect 2.6.32.9 also as gregkh took the original 803bf5ec259941936262d10ecc84511b76a20921 patch but not the new one since it wasn't in Linus' tree until after .9 was release.  

I've asked gregkh to take it for .10.