Bug 15308 - 2.6.33-rc8 breaks UML with Restrict initial stack space expansion to rlimit
Summary: 2.6.33-rc8 breaks UML with Restrict initial stack space expansion to rlimit
Status: CLOSED CODE_FIX
Alias: None
Product: Platform Specific/Hardware
Classification: Unclassified
Component: UML (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jeff Dike
URL:
Keywords:
Depends on:
Blocks: 14885
  Show dependency tree
 
Reported: 2010-02-14 23:20 UTC by Rafael J. Wysocki
Modified: 2010-02-23 23:56 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.33-rc8
Tree: Mainline
Regression: Yes


Attachments

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.

Note You need to log in before you can comment on or make changes to this bug.