From: Michael Neuling <mikey@neuling.org>
To: Jouni Malinen <j@w1.fi>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
linux-kernel@vger.kernel.org
Subject: Re: 2.6.33-rc8 breaks UML with Restrict initial stack space expansion to rlimit
Date: Mon, 15 Feb 2010 09:03:39 +1100 [thread overview]
Message-ID: <9296.1266185019@neuling.org> (raw)
In-Reply-To: <20100214164023.GA2726@jm.kir.nu>
In message <20100214164023.GA2726@jm.kir.nu> you wrote:
> It looks like the commit 803bf5ec259941936262d10ecc84511b76a20921
> (fs/exec.c: restrict initial stack space expansion to rlimit) broke my
> user mode Linux setup by somehow preventing system setup from running
> properly (or killing some processes that try to mount things, etc.).
> This commit turned up as the reason based on git bisect and reverting it
> fixes my UML test setup (Ubuntu 9.10 on both host and in UML and AMD64
> arch for both). I have no idea what exactly would be the main cause for
> this issue, but this looks like a somewhat unfortunately timed
> regression in 2.6.33-rc8.
>
> The failed run shows like this (with current linux-2.6.git):
>
> ...
> EXT3-fs (ubda): mounted filesystem with writeback data mode
> VFS: Mounted root (ext3 filesystem) readonly on device 98:0.
> IRQ 3/console-write: IRQF_DISABLED is not guaranteed on shared IRQs
> IRQ 2/console: IRQF_DISABLED is not guaranteed on shared IRQs
> IRQ 10/winch: IRQF_DISABLED is not guaranteed on shared IRQs
> IRQ 10/winch: IRQF_DISABLED is not guaranteed on shared IRQs
> mountall: mount /sys/kernel/debug [218] killed by KILL signal
> mountall: Filesystem could not be mounted: /sys/kernel/debug
> mountall: mount /dev [219] killed by KILL signal
> mountall: Filesystem could not be mounted: /dev
> mountall: mount /tmp [220] killed by KILL signal
> mountall: Filesystem could not be mounted: /tmp
> mountall: mount /var/lock [222] killed by KILL signal
> mountall: Filesystem could not be mounted: /var/lock
> ...
>
>
> With 803bf5ec reverted, UML comes up and the output looks like this:
>
> ...
> EXT3-fs (ubda): mounted filesystem with writeback data mode
> VFS: Mounted root (ext3 filesystem) readonly on device 98:0.
> IRQ 3/console-write: IRQF_DISABLED is not guaranteed on shared IRQs
> IRQ 2/console: IRQF_DISABLED is not guaranteed on shared IRQs
> IRQ 10/winch: IRQF_DISABLED is not guaranteed on shared IRQs
> IRQ 10/winch: IRQF_DISABLED is not guaranteed on shared IRQs
> init: procps main process (226) terminated with status 255
> fsck from util-linux-ng 2.16
> ...
Crud, the "killed" is definitely something this patch could cause.
I'm not familiar with UML. Is this the guest and the host booting rc8,
or just the host? Does UML use stack protection at all?
Can you try booting the guest to init=/bin/sh and try running some tests
to see what you can set 'ulimit -s' to and still be able to run a simple
command like '/bin/ls'?
Mikey
>
> --
> Jouni Malinen PGP id EFC895FA
>
next prev parent reply other threads:[~2010-02-14 22:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-14 16:40 2.6.33-rc8 breaks UML with Restrict initial stack space expansion to rlimit Jouni Malinen
2010-02-14 22:03 ` Michael Neuling [this message]
2010-02-15 2:38 ` KOSAKI Motohiro
2010-02-15 7:02 ` Jouni Malinen
2010-02-15 6:56 ` Jouni Malinen
2010-02-14 23:23 ` Rafael J. Wysocki
2010-02-15 6:30 ` Michael Neuling
2010-02-15 6:59 ` KOSAKI Motohiro
2010-02-15 7:17 ` Jouni Malinen
2010-02-15 8:57 ` [PATCH] exec/fs: fix initial stack reservation Michael Neuling
2010-02-15 9:04 ` KOSAKI Motohiro
2010-02-15 9:08 ` Américo Wang
2010-02-15 8:57 ` 2.6.33-rc8 breaks UML with Restrict initial stack space expansion to rlimit Américo Wang
2010-02-15 9:03 ` KOSAKI Motohiro
2010-02-15 7:12 ` Jouni Malinen
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=9296.1266185019@neuling.org \
--to=mikey@neuling.org \
--cc=j@w1.fi \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
/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