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.
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
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
Handled-By : Michael Neuling <mikey@neuling.org> Patch : http://patchwork.kernel.org/patch/79365/
This is now upstream as a17e18790a8c47113a73139d54a375dc9ccd8f08 (fs/exec.c: fix initial stack reservation).
Thanks, closing.
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.