lkml.org 
[lkml]   [2010]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: 2.6.33-rc8 breaks UML with Restrict initial stack space expansion to rlimit
    Date
    > 
    >
    > 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
    > > ...

    Wow. It seems very strange. Usually stack overflow makes SIGSEGV, not SIGKILL.
    plus, In my environment (x86_64 non-uml), mount command doesn't use
    the stack so much.


    % /usr/bin/time --format="mem %M" ls
    /usr/bin/time --format="mem %M" ls
    GPATH INSTALL README configure fdisk lib misc-utils schedutils
    mem 3232

    % sudo /usr/bin/time --format="mem %M" mount -a
    sudo /usr/bin/time --format="mem %M" mount -a
    mem 2992


    Hmmm...
    I have no idea.



    > >
    > >
    > > 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
    > >
    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    > Please read the FAQ at http://www.tux.org/lkml/





    \
     
     \ /
      Last update: 2010-02-15 03:41    [W:0.031 / U:1.940 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site